Нравится ли вам синтаксис Linq? В минималистичном виде:

from e in list where e % 2 select e

Что бы вы хотели в нем поменять? Возможно, сделать более кратким или наоборот.
Скажем, если рассматривать этот вопрос без учета "совместимости" с интелли-сенсом.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Нравится ли вам синтаксис Linq?

Предпочитаю манипулировать стандартными ФВП, хотя в C# это получается тяжеловесней, чем в F#/Haskell (зато единообразно). Query comprehesion syntax делали в угоду программистам, знакомым с SQL. Я же SQL как не знал, так и не знаю :) Так что мне такой синтаксический сахар не сладок.

Здравствуйте, Qbit86, Вы писали:

Q>Предпочитаю манипулировать стандартными ФВП, хотя в C# это получается тяжеловесней, чем в F#/Haskell (зато единообразно). Query comprehesion syntax делали в угоду программистам, знакомым с SQL. Я же SQL как не знал, так и не знаю Так что мне такой синтаксический сахар не сладок.

Linq — это скорее генератор, он все же ленивый. Но суть не в этом.
Ну а что бы хотели видеть вместо Linq-a? Синтаксис я имею в виду. С учетом того, что C# язык весьма Си-подобный и классическая Set Builder нотация могла бы "сорвать крышу" многим пользователям.
Плюс Linq таки "круче" стандартных генераторов — есть и orderby, group by и let. Я, например, с трудом представляю, как все это впихнуть в хаскелевский list comprehension, чтобы не получилась каша.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>...и классическая Set Builder нотация могла бы "сорвать крышу" многим пользователям... Я, например, с трудом представляю, как все это впихнуть в хаскелевский list comprehension, чтобы не получилась каша.

Я не про set buider и не про list comprehension, я про стандартные ФВП вроде map—filter—fold/reduce (и их C#-аналоги Select—Where—Aggregate).

ВВ>Плюс Linq таки "круче" стандартных генераторов — есть и orderby, group by и let.

Всё, что можно выразить в терминах query comprehension syntax, можно выразить и в терминах ФВП (хоть и не всегда лаконично). Так, например, есть extension-методы OrderBy/ThenBy и GroupBy, let же воспроизводится введением промежуточного кортежа (в C# удобно использовать синтаксис анонимных классов). Кроме того, есть много других полезных ФВП, которые через query comprehension syntax не выражаются. Приходится «смешивать языки» — часть запроса писать на SQL-подобном языке, затем оборачивать в скобки и добавлять вызов C# extension-методов — получается немного эклектичненько.

ВВ>Linq — это скорее генератор, он все же ленивый.

Лень никуда не девается. Linq ничего нового в рамках CLR или ядра языка не предоставляет, всё в результате компилируется в обычные сатические функции, возвращающие санки.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Нравится ли вам синтаксис Linq? В минималистичном виде:

ВВ>

ВВ>from e in list where e % 2 select e
ВВ>

Кошмарный синтаксис. Зачем-то ввели в язык кучу новых конструкций и ключевых слов ничего не выиграв ни в лаконичности, ни в читабельности.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Нравится ли вам синтаксис Linq? В минималистичном виде:

ВВ>

ВВ>from e in list where e % 2 select e
ВВ>

ВВ>Что бы вы хотели в нем поменять? Возможно, сделать более кратким или наоборот.
ВВ>Скажем, если рассматривать этот вопрос без учета "совместимости" с интелли-сенсом.

Неправильный синтаксис, нелогичный.
Чем плох стандартный:

select e from list where e % 2

???

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Что бы вы хотели в нем поменять? Возможно, сделать более кратким или наоборот.

Скобочек добавить

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Нравится ли вам синтаксис Linq?
"Ненавижу и стремлюсь уничтожить" (с)
Linq применяю только в синтаксисе extention-методов c лямбдами.

Здравствуйте, geniepro, Вы писали:

G>Неправильный синтаксис, нелогичный.
G>Чем плох стандартный:

G>

G>select e from list where e % 2 
G>

G>???

Тем что после ввода клоза select не работает intellisence.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Нравится ли вам синтаксис Linq? В минималистичном виде:

ВВ>

ВВ>from e in list where e % 2 select e
ВВ>

ВВ>Что бы вы хотели в нем поменять? Возможно, сделать более кратким или наоборот.

А что бы не разрешить все варианты, как в Хаскелле. Хочешь — comprehension:

[i | i <- list, odd i]

хочешь — монады:

list >>= 
\i -> guard (odd i) >> 
return i

хочешь — императивный сахар вокруг монад

do i <- list
   guard (odd i)
   return i

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Нравится ли вам синтаксис Linq? В минималистичном виде:

ВВ>

ВВ>from e in list where e % 2 select e
ВВ>

ВВ>Что бы вы хотели в нем поменять? Возможно, сделать более кратким или наоборот.

В нем есть ровно два лишних элемента from и select. По уму он не должен отличаться от вызова соответствующих функций:

where e % 2

ВВ>Скажем, если рассматривать этот вопрос без учета "совместимости" с интелли-сенсом.

А интелисенс тут вообще никаким боком не влияет ни на что. Это чистые заморочки тех кто придумывал синтаксис. Обязательное наличие from уменьшает количество ключевых слов которое нужно контролировать в обычных выражениях для того чтобы выявить линк-выражение, а обязательное наличие select позволяет упростить выявление окончания линк-выражения. Можно было пойти другим путем — ввести специальное ключевое слово или символ предваряющее запрос или заставить брать запрос в скобки при неоднозначностьях.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Нравится ли вам синтаксис Linq? В минималистичном виде:

ВВ>

ВВ>from e in list where e % 2 select e
ВВ>

Нравится все, гораздо лучше синтаксиса SQL-я.
Не хватает: возможности использовать номер строки (доступно через extension-метод) + хотелось бы в join использовать произвольне условие, а не только равенство (эмулируется через доп. from + where, но выглядит корявее).

Здравствуйте, VladD2, Вы писали:

ВВ>>Что бы вы хотели в нем поменять? Возможно, сделать более кратким или наоборот.
VD>В нем есть ровно два лишних элемента from и select. По уму он не должен отличаться от вызова соответствующих функций:
VD>

VD>where e % 2
VD>

А как писать выражение для выборки? Ну т.е. select — это же просто (забыл умное слово) средство для трансформации списка.
Кстати, в Немерле, я так вижу, синтаксис воспроизведен один в один. Или это сделано из политических соображений?

ВВ>>Скажем, если рассматривать этот вопрос без учета "совместимости" с интелли-сенсом.
VD>А интелисенс тут вообще никаким боком не влияет ни на что. Это чистые заморочки тех кто придумывал синтаксис. Обязательное наличие from уменьшает количество ключевых слов которое нужно контролировать в обычных выражениях для того чтобы выявить линк-выражение, а обязательное наличие select позволяет упростить выявление окончания линк-выражения. Можно было пойти другим путем — ввести специальное ключевое слово или символ предваряющее запрос или заставить брать запрос в скобки при неоднозначностьях.

Ну мне казалось, это одна из причин, почему from идет перед select — ведь в противном случае мы не знаем тип выражения, которое пишется в select, и интелли-сенс работать не будет.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Ну т.е. select — это же просто (забыл умное слово) средство для трансформации списка.

Проекция или отображение.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>А как писать выражение для выборки? Ну т.е. select — это же просто (забыл умное слово) средство для трансформации списка.

Слово называется — отображение. Ну, так если оно нужно, то его нужно и использовать. Просто глупо что-то использовать только из соображений синтаксических предпочтений создателей языка.

ВВ>Кстати, в Немерле, я так вижу, синтаксис воспроизведен один в один. Или это сделано из политических соображений?

Селект можно опускать.

ВВ>Ну мне казалось, это одна из причин, почему from идет перед select — ведь в противном случае мы не знаем тип выражения, которое пишется в select, и интелли-сенс работать не будет.

Причина этого синтаксиса одна — предпочтения его разработчика.

Здравствуйте, VladD2, Вы писали:

VD>Причина этого синтаксиса одна — предпочтения его разработчика.

А что должен вернуть такой запрос:

from a in aaa
from b in bbb

Здравствуйте, VladD2, Вы писали:

ВВ>>Кстати, в Немерле, я так вижу, синтаксис воспроизведен один в один. Или это сделано из политических соображений?
VD>Селект можно опускать.

Так претензия только в том, что в Линке селект нельзя опускать?

ВВ>>Ну мне казалось, это одна из причин, почему from идет перед select — ведь в противном случае мы не знаем тип выражения, которое пишется в select, и интелли-сенс работать не будет.
VD>Причина этого синтаксиса одна — предпочтения его разработчика.

Ну а какой бы ты выбрал синтаксис, если бы не было необходимости поддерживать совместимость с Линком?

Здравствуйте, Lloyd, Вы писали:

L>А что должен вернуть такой запрос:
L>

L>from a in aaa
L>from b in bbb
L>

Ну кстати да, даже в насквозь математической Set Builder нотации есть специальный обязательный clause, с которого начинается все выражение и который как раз полностью дублирует select по своему смыслу.

А вот "from a" это халтура, так как служит исключительно для ввода переменной, тогда как для этой же цели можно было использовать и select.

Здравствуйте, Lloyd, Вы писали:

L>А что должен вернуть такой запрос:
L>

L>from a in aaa
L>from b in bbb
L>

Тоже, что и такой код:

aaa.SelectMany(a => ...)

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Ну а какой бы ты выбрал синтаксис, если бы не было необходимости поддерживать совместимость с Линком?

Я бы его вообще не вводил, если честно.

Для работы с СУБД я бы создал специализированный язык базирующийся на SQL-03 (или какой там текущий стандарт?) и встроил бы его в язык. А ЛИНК оставил бы в виде библиотеки.

Единственное где удобен синтаксис — это в join. Но join чаще встречается при работе с БД.

Здравствуйте, VladD2, Вы писали:

VD>Тоже, что и такой код:

VD>

VD>aaa.SelectMany(a => ...)
VD>

Т.е. b? И чем такой вариант лучше? Имхо, не очень-то очевидный результат.
Например:
было:

var q = from a in aaa 
        from b in bbb
        where a > b;

Решили отрефакторить (фильтровать опционально):

var q = from a in aaa 
        from b in bbb;
if (needFilter) {
  q = from x in q
      where ....
}

И что теперь в where писать?

Здравствуйте, VladD2, Вы писали:

ВВ>>Ну а какой бы ты выбрал синтаксис, если бы не было необходимости поддерживать совместимость с Линком?
VD>Я бы его вообще не вводил, если честно.

Интересно, когда я высказывал свое "фе" в отношении Линка, ты достал свой мазер

VD>Для работы с СУБД я бы создал специализированный язык базирующийся на SQL-03 (или какой там текущий стандарт?) и встроил бы его в язык. А ЛИНК оставил бы в виде библиотеки.

Ну т.е. для работы с коллекциями использовались бы только экстеншин-методы? И специальный синтаксис тут (если вообще не рассматривать Линк в связи с СУБД) не нужен?
Но вот, например, большинство ФЯ вводят специальный синтаксис для list/generator comprehension, хотя все это тоже можно выразить через ФВП. Специальный синтаксис, видимо, удобнее

Вот если рассматривать Линк как generator comprehension + дополнительные фишки (сортировка, join-ы и пр.), то вроде бы как Линк — вполне нормальная идея. Или нет?
И если нормальная, то как мог бы выглядеть его синтаксис в "идеальном языке"? Положим, что SQL-подобие необязательно, но нужно сохранить все его текущие фишки.

Здравствуйте, Lloyd, Вы писали:

Необязательный select != отсутствие select-a.

Тебе, я так понимаю, нравится синтаксис Linq-a. Но ведь во многих случаях при использовании экстеншин-методов код получается значительно более лаконичным, чем в случае использования специализированного синтаксиса.

Вот не баг ли это в этом "специализированном" синтаксисе?

Здравствуйте, Lloyd, Вы писали:

VD>>

VD>>aaa.SelectMany(a => ...)
VD>>

L>Т.е. b?

У тебя правда проблемы с пониманием функций линка, или снова много времени которые не на что больше потратить?

SelectMany позволяет получить пересечение двух списков. Тоже самое делает и вложенный from.

L>И чем такой вариант лучше?

Чем что?

L> Имхо, не очень-то очевидный результат.

В жизни бывают разные задачи. В каких-то случаях общий паттерн определяется только с select. В каких-то select нужен просто для трансформации данных (вместо Map). В каких-то случаях select на фиг не нужен.

Не ужели это не очевидно?

ЗЫ

В качестве примера...
Буквально недавно рефакторил код одного макроса. Там был вот такой код:
http://code.google.com/p/nemerle/source/diff?spec=svn8651&r=8651&format=side&path=/nemerle/trunk/snippets/peg-parser/LRPEGCC/RuleCompiler.Handlers.n

match(this)
{
  | SuperBlock(bs)          =>
    mutable l = [];
    foreach(b in bs)
      l = l + b.GetLinearBlockList();
    l
  | _                       => [this]
}

Не трудно догадаться, что использование сложения списков приводило к экспоненциальному росту тормозов.
Я заменил этот код на:

match(this)
{
  | SuperBlock(bs) => bs.SelectMany(b => b.GetLinearBlockList())
  | _              => [this]
}

Почему этот же код нельзя записать как:

match(this)
{
  | SuperBlock(bs) => from x in b.GetLinearBlockList() from b in bs
  | _              => [this]
}

Зачем мне к "from x in b.GetLinearBlockList() from b in bs" дописывать select?

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Интересно, когда я высказывал свое "фе" в отношении Линка, ты достал свой мазер

Линк слишком обширное понятие. Как библиотека линк — великолепен.

Синтаксис в сложных случаях тоже не плох. Для коротких запросов (которых большинство) конечно он несколько громоздок.
К тому же синтаксис придуман для облегчения вхождения новичков. Я к таковым уже не отношусь. Так что мне он не особо нужен.

ВВ>Ну т.е. для работы с коллекциями использовались бы только экстеншин-методы? И специальный синтаксис тут (если вообще не рассматривать Линк в связи с СУБД) не нужен?

Синтаксис нужен новичков. Он облегчает вход для них. Так что у него другие задачи.
А так, да. Для 90% задач синтаксис обычно не нужен. Но и его наличие не особо напрягает. Читается то код неплохо. Шум есть, но в пределах разумного.

ВВ>Но вот, например, большинство ФЯ вводят специальный синтаксис для list/generator comprehension, хотя все это тоже можно выразить через ФВП. Специальный синтаксис, видимо, удобнее

Дык и там тоже чаще ФВП используются. Потом синтаксис list comprehension зачастую хотя и удобен для написания, но плох для понимания окружающими.

ВВ>Вот если рассматривать Линк как generator comprehension + дополнительные фишки (сортировка, join-ы и пр.), то вроде бы как Линк — вполне нормальная идея. Или нет?

Так и есть. Только не "generator", а "query comprehension".

ВВ>И если нормальная, то как мог бы выглядеть его синтаксис в "идеальном языке"? Положим, что SQL-подобие необязательно, но нужно сохранить все его текущие фишки.

Дык не бывает идеального языка. Люди могут иметь разный уровень подготовки. Разные вкусы. Разные потребности, в конце концов.

Здравствуйте, VladD2, Вы писали:

L>>Т.е. b?

VD>У тебя правда проблемы с пониманием функций линка, или снова много времени которые не на что больше потратить?

Речь не обо мне, если ты не заметил, а о синтксесе линка в Nemerle. Вопрос преждний — b или не-b?

L>>И чем такой вариант лучше?

VD>Чем что?

Чем вариант linq-а C#.

L>> Имхо, не очень-то очевидный результат.

VD>В жизни бывают разные задачи. В каких-то случаях общий паттерн определяется только с select. В каких-то select нужен просто для трансформации данных (вместо Map). В каких-то случаях select на фиг не нужен.

VD>Не ужели это не очевидно?

Задачи бывают разные, кто ж спорит то. Но где связь м.у задачами и синтаксисом линка в N?
Или это такой риторический прием, подсунуть собеседнику вопрос, с которым он гарантированно согласится, а затем рассматривать его (согласие) как согласие с начальной посылкой?

VD>

VD>Зачем мне к "from x in b.GetLinearBlockList() from b in bs" дописывать select?

Потому что, два from вводят 2 переменные в облась видимости select-а. Почему в качестве результирующей выбрана именно последняя, мне не до конца понятно. Почему такой выбор считается кем-то лучшим, чем явное указание возвращаемого значения — непонятно вдвойне.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Необязательный select != отсутствие select-a.

ВВ>Тебе, я так понимаю, нравится синтаксис Linq-a. Но ведь во многих случаях при использовании экстеншин-методов код получается значительно более лаконичным, чем в случае использования специализированного синтаксиса.

ВВ>Вот не баг ли это в этом "специализированном" синтаксисе?

Да, иногда с extension-методами получается лаконичнее.

Баг ли это — не знаю, но я не могу придумать другого варианта синтаксиса, который сохранил бы выразительности linq-а и при этом оставался бы лаконичным в вышеописанных случаях.

Здравствуйте, VladD2, Вы писали:

VD>Для работы с СУБД я бы создал специализированный язык базирующийся на SQL-03 (или какой там текущий стандарт?) и встроил бы его в язык.

Гм. А в чем цимес использования синтаксиса sql-я. Только совместимость с SQL-м или ты считаешь, что ситаксис SQL для запросов чем-то лучше?

Здравствуйте, Lloyd, Вы писали:

VD>>Для работы с СУБД я бы создал специализированный язык базирующийся на SQL-03 (или какой там текущий стандарт?) и встроил бы его в язык.
L>Гм. А в чем цимес использования синтаксиса sql-я. Только совместимость с SQL-м или ты считаешь, что ситаксис SQL для запросов чем-то лучше?

Так предложи альтернативный синтаксис, который будет лучше для запросов, чем SQL-подобный. Я, собственно, этого и жду

Здравствуйте, Воронков Василий, Вы писали:

L>>Гм. А в чем цимес использования синтаксиса sql-я. Только совместимость с SQL-м или ты считаешь, что ситаксис SQL для запросов чем-то лучше?

ВВ>Так предложи альтернативный синтаксис, который будет лучше для запросов, чем SQL-подобный. Я, собственно, этого и жду

Если честно, linq мне кажется для запросо удобнее sql-я, за исключением уже упомянутого join-а.

Здравствуйте, Lloyd, Вы писали:

VD>>Для работы с СУБД я бы создал специализированный язык базирующийся на SQL-03 (или какой там текущий стандарт?) и встроил бы его в язык.

L>Гм. А в чем цимес использования синтаксиса sql-я. Только совместимость с SQL-м или ты считаешь, что ситаксис SQL для запросов чем-то лучше?

Почему только синтаксис? Семантику тоже.

Лучше это там, что позволяет использовать большую часть возможностей SQL-сервера (любого) и работать с привычным языком не думая о том как какой-то там провайдер перепишет твой запрос в реальный SQL.

Вообще идея встроенного SQL-я стара как мир. Все что к ней нужно было сделать — это прикрутить качественную интеграцию в язык:
* Сделать статически типизированную проверяемую во время компиляции связку с данными приложениями (на подобии линка).
* Качественную материализацию данных сервера в объектв.
* Из Линка имело бы смысл повзаимствовать идею ассациаций, чтобы вместо join-ов писать удобные и простые в понимании обращения к вложенным "свойствам".

Но при этом это должен быть именно SQL. Вплоть до поддержки DDL и триггеров.

Здравствуйте, Lloyd, Вы писали:

L>Речь не обо мне, если ты не заметил, а о синтксесе линка в Nemerle. Вопрос преждний — b или не-b?

В Nemerle реализована версия очень близкая к C#. Единственно, что можно опускать select в тех случаях где и без него можно легко обойтись.

L>Задачи бывают разные, кто ж спорит то. Но где связь м.у задачами и синтаксисом линка в N?

Это ты ее хочешь найти. Я просто сказал, что есть простые случаи где синтаксис линка избыточен. И привел пример такого случая — фильтрация данных. А ты снова полез в бутылку.

L>Потому что, два from вводят 2 переменные в облась видимости select-а. Почему в качестве результирующей выбрана именно последняя, мне не до конца понятно. Почему такой выбор считается кем-то лучшим, чем явное указание возвращаемого значения — непонятно вдвойне.

Если тебе нужно что-то другое используй селект. В тех местах где он нужен — он нужен. Но есть масса случаев когда он не нужен.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Нравится ли вам синтаксис Linq? В минималистичном виде:

ВВ>ВВ>from e in list where e % 2 select e
ВВ>


ВВ>Что бы вы хотели в нем поменять? Возможно, сделать более кратким или наоборот.

Здесь любой навороченный синтаксис будет излишним. Эти ключевые слова хорошо выглядят когда есть что-то хотя бы в select и where. И то этого мало,

желательно еще хотя бы одно из: join, sort, group, let.

А здесь даже list.Where(e=> e%2) кажется излишним, ИМХО. В последнее время я перестал давать буквенные имена когда один параметр у лямбды.
Так,ИМХО лучше: list.Where(_=> _%2)
Не нужно смотреть на параметр лямбды, и не спутаешь с именем захваченой внешней переменной.
Если бы был на клаве еще один свободный символ я бы ввел такое сокращение:
list.Where(@%2==0 && @>10) равнозначно list.Where(e => e%2==0 && e>10)

Здравствуйте, VladD2, Вы писали:

L>>Гм. А в чем цимес использования синтаксиса sql-я. Только совместимость с SQL-м или ты считаешь, что ситаксис SQL для запросов чем-то лучше?

VD>Почему только синтаксис? Семантику тоже.

VD>Лучше это там, что позволяет использовать большую часть возможностей SQL-сервера (любого) и работать с привычным языком не думая о том как какой-то там провайдер перепишет твой запрос в реальный SQL.

Дык, sql-то этот от базы к базе — разный. Тот же пейджинг на mssql-е будет записан одним способом, а на oracle-е совершенно другим. Как это обходить? Или под каждый сервер базы данных писать свое расширение языка?

Здравствуйте, Lloyd, Вы писали:

L>Дык, sql-то этот от базы к базе — разный.

SQL-92 поддерживают почти все серверы из числа что хоть что-то стоят. Точнее его сабсэт применимый на практике. Кое что можно будет эмулировать.

L>Тот же пейджинг на mssql-е будет записан одним способом, а на oracle-е совершенно другим. Как это обходить?

А что мешает это реализовать в виде функций (как в линке)?

L>Или под каждый сервер базы данных писать свое расширение языка?

Нужно реализовать общий сабсэт стандарта плюс нужные расширения. Так же как и в случае линк-провайдеров, если сервер не реализует какой-то функциональности, ее можно эмулировать (в разумных пределах).

Здравствуйте, Lloyd, Вы писали:

L>Дык, sql-то этот от базы к базе — разный.

Он разный только в деталях, семантика всех современных диалектов очень близка. Чего не скажешь о LINQ, семантика которого от SQL отличается очень сильно. Из-за этого создание провайдера LINQ для РСУБД мягко говоря очень нетривиальная задача.

Здравствуйте, gandjustas, Вы писали:

G>Тем что после ввода клоза select не работает intellisence.

А после ввода from работает?

Здравствуйте, deniok, Вы писали:

D>А что бы не разрешить все варианты, как в Хаскелле. Хочешь — comprehension:

Ещё забыл PM (выбрать веса всех барашкиных какашек, коровкины пропустить)

data Shit = ShipShit Int | CowShit Int

[w | ShipShit w <- fieldOfShit]

Здравствуйте, VladD2, Вы писали:

Два вопроса.

VD>Я заменил этот код на:
VD>

VD>match(this)
VD>{
VD>  | SuperBlock(bs) => bs.SelectMany(b => b.GetLinearBlockList())
VD>  | _              => [this]
VD>}
VD>

Вопрос, не относящийся к теме:
А разве b => b.GetLinearBlockList() не идентичен _.GetLinearBlockList()?

VD>Почему этот же код нельзя записать как:
VD>

VD>match(this)
VD>{
VD>  | SuperBlock(bs) => from x in b.GetLinearBlockList() from b in bs
VD>  | _              => [this]
VD>}
VD>

Вопрос, относящийся к теме:
А разве не лучше и от from здесь избавиться? Переменная x кажется лишней.

Пример

select many b.GetLinearBlockList() from b in bs

Здравствуйте, lomeo, Вы писали:

L>Здравствуйте, gandjustas, Вы писали:

G>>Тем что после ввода клоза select не работает intellisence.

L>А после ввода from работает?

Да

Когда пишу в ssms сначала ставлю звездочку в select, пишу в from имя таблицы, предикаты, а потом указываю в select проекцию

Здравствуйте, gandjustas, Вы писали:

G>>>Тем что после ввода клоза select не работает intellisence.
L>>А после ввода from работает?
G>Да

М? Я хочу написать обсуждаемое выражение

from e in list where e % 2 select e

Ввёл "from". Как IDE догадается, что там нужно "e"?

G>Когда пишу в ssms сначала ставлю звездочку в select, пишу в from имя таблицы, предикаты, а потом указываю в select проекцию

Не понял при чём тут это — мы говорим о LINQ вроде.

Здравствуйте, lomeo, Вы писали:

L>Здравствуйте, gandjustas, Вы писали:

G>>>>Тем что после ввода клоза select не работает intellisence.
L>>>А после ввода from работает?
G>>Да

L>Не понял при чём тут это — мы говорим о LINQ вроде.
Я про SQL вообще-то.

Поэтому в linq ситуация получше, сначала вводиттся from in и сразу работает intellisence.

Здравствуйте, lomeo, Вы писали:

L>Ещё забыл PM (выбрать веса всех барашкиных какашек, коровкины пропустить)

L>

L>data Shit = ShipShit Int | CowShit Int
L>

У вас тут кораблиные какашки.

Здравствуйте, gandjustas, Вы писали:

G>Я про SQL вообще-то.
G>Поэтому в linq ситуация получше, сначала вводиттся from in и сразу работает intellisence.

Ясно, спасибо.

Здравствуйте, achp, Вы писали:

A>У вас тут кораблиные какашки.

Как же это я? О чём то своём думал когда писал

Здравствуйте, Silver_s, Вы писали:

S_>Если бы был на клаве еще один свободный символ я бы ввел такое сокращение:
S_>list.Where(@%2==0 && @>10) равнозначно list.Where(e => e%2==0 && e>10)

Кстати, было бы неплохо иметь сокращенный синтаксис лямбд с одним аргументом, типа

@@ + 1 эквивалентно a => a + 1

Не могу правда сразу сообразить, что это может поломать.