Здравствуйте, VladD2, Вы писали:
ВВ>>Ну а какой бы ты выбрал синтаксис, если бы не было необходимости поддерживать совместимость с Линком? VD>Я бы его вообще не вводил, если честно.
Интересно, когда я высказывал свое "фе" в отношении Линка, ты достал свой мазер
VD>Для работы с СУБД я бы создал специализированный язык базирующийся на SQL-03 (или какой там текущий стандарт?) и встроил бы его в язык. А ЛИНК оставил бы в виде библиотеки.
Ну т.е. для работы с коллекциями использовались бы только экстеншин-методы? И специальный синтаксис тут (если вообще не рассматривать Линк в связи с СУБД) не нужен?
Но вот, например, большинство ФЯ вводят специальный синтаксис для list/generator comprehension, хотя все это тоже можно выразить через ФВП. Специальный синтаксис, видимо, удобнее
Вот если рассматривать Линк как generator comprehension + дополнительные фишки (сортировка, join-ы и пр.), то вроде бы как Линк — вполне нормальная идея. Или нет?
И если нормальная, то как мог бы выглядеть его синтаксис в "идеальном языке"? Положим, что SQL-подобие необязательно, но нужно сохранить все его текущие фишки.
Тебе, я так понимаю, нравится синтаксис Linq-a. Но ведь во многих случаях при использовании экстеншин-методов код получается значительно более лаконичным, чем в случае использования специализированного синтаксиса.
Вот не баг ли это в этом "специализированном" синтаксисе?
У тебя правда проблемы с пониманием функций линка, или снова много времени которые не на что больше потратить?
SelectMany позволяет получить пересечение двух списков. Тоже самое делает и вложенный from.
L>И чем такой вариант лучше?
Чем что?
L> Имхо, не очень-то очевидный результат.
В жизни бывают разные задачи. В каких-то случаях общий паттерн определяется только с select. В каких-то select нужен просто для трансформации данных (вместо Map). В каких-то случаях 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 для РСУБД мягко говоря очень нетривиальная задача.
... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, gandjustas, Вы писали:
G>>Тем что после ввода клоза select не работает intellisence.
L>А после ввода from работает?
Да
Когда пишу в ssms сначала ставлю звездочку в select, пишу в from имя таблицы, предикаты, а потом указываю в select проекцию