Здравствуйте, 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 проекцию