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

WH>Но меня данная операция всегда напрягала.
WH>И что характерно всех моих знакомых тоже.

Насколько часто это приходится делать?

O>> Кстати, авторам грамматик со сложной, многоуровневой системой приоритетов, вылезающей за пределы привычной со школы арифметики, надо отрубать руки. За садизм и бесчеловечность. Больше трех уровней это уже садизм и мизантропия.
WH>Да я бы не сказал.

Вам нравятся грамматики со сложными правилами приоритетов? А я вот такой код читать не могу совершенно, если там есть что-то сложнее школьной арифметики. И писать такой код не могу, я всегда скобочки расставляю явным образом. Не хочу и не могу помнить, больше у '%' приоритет чем у '+' или меньше.

O>> А вот числовые приоритеты как раз для восприятия сложнее. Это их еще сравнивать надо, а тут тупо список, те что пониже приоритетом идут вперед, что повыше в конце.
WH>Не могу согласиться. Люди настолько привыкли к числам, что сравнивают их на больше/меньше не приходя в сознание.

Не все. Мне вот даже ценники в магазине сравнивать непросто. И таких как я много. Может это и форма дислексии, но она очень распространена. Ненавижу цифры.

WH>Это делается в основном для динамического расширения.
WH>Чтобы человек всегда мог добавить новый приоритет.

Можно добавить пустых термов. Но лучше уж бить по рукам и не позволять добавлять приоритеты. Трех более чем достаточно.

O>> Правая то и так без мемоизации получается. Левая интереснее.
WH>У меня обе без мемоизации работают. Ключевые слова Pratt parser.
WH>У меня алгоритм основа на нем.

Как-то информации по нему мало, кроме самой оригинальной статьи.

O>> Работает. Единственное ограничение — нельзя леворекурсивые правила добавлять в нелеворекурсивные. Это если мы их оптимизируем. Если нет — то можно, не проблема.
WH>А у меня ограничений нет. Все очень просто. Быстро. И линейно.

Совсем нет? Так не бывает. Но вы меня заинтересовали, попробую узнать про Pratt-а побольше. Есть какие-то ссылки по теме, которые гугл и википедия не дадут?

Естественно, воспользоваться я этим смогу только если алгоритм позволяет писать парсеры руками, на C или шарпе, без всяких генераторов.

O>> Практика прямо таки кричит, что сложных грамматик быть вообще не должно. Сколько можно C++-ы изобретать?
WH>Да я не спорю. Но существующие языки тоже нужно разбирать.

К задаче реализации DSL это особого отношения не имеет, к счастью.

O>> Если кто-то попробует сделать DSL с синтаксисом шарпа, то ему надо отрубить обе руки. За садизм и бесчеловечность. Потом и документацию на тысячу страниц писать, с описанием тонкостей приоритетов операторов?
WH>Описание приоритетов задается одной маленькой табличкой.

Которая в голове, однако, не помещается.

O>>А как насчет highlighting? Можно распарсить только измененный регион текста, без мемоизации?
WH>Мне хватает скорости, чтобы все распарсить.

Даже если там сто тысяч строк кода?

O>> Естественно. И даже так полно исключительных случаев, когда надо ругнуться более умно, чем любой генератор парсеров позволит. Как в clang, например — "а не забыли ли вы скобки вокруг параметров оператора &&? точно-точно?"
WH>Я это понимаю. И собираюсь сделать язык описания ошибочных ситуаций.

А это не ошибочная ситуация. Это предупреждение.

WH>Это позволит очень просто задавать сообщения для подобных случаев.

Очень интересно. Я пока что не представляю себе, как это можно сделать декларативно.

O>> Я репрезентативен,
WH>Я о том, что далеко не всем людям понятно даже это:

Для понимания всем хватает тридцати минут, раз и навсегда. Проверенно.

WH>>>https://github.com/rsdn/nemerle/tree/master/snippets/peg-parser
O>> Посмотрю.
WH>Да не на что там смотреть.

Мне Packrat интересен как раз тем, что его можно и руками делать, без DSLей, без генераторов.

O>> Так что не так-то с динамической расширяемостью? Чем меньше декларативности, тем ее проще реализовывать, разве нет?
WH>Нет. Чем меньше декларативности, тем мутнее семантика языка.
WH>Тем сложнее рассуждать о поведении грамматики при динамическом расширении.

Семантика то как раз прозрачна, поскольку не далеко ушла от привычной семантики низлежащего языка.

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

VD>Но пока читал все это сформулировал для себя очень простой критерий выявления ДСЛ-ей. ДСЛ не позволяет воспроизвети себя же, если это не ДСЛ описания компилятора.

Влад, я с этим не согласен. Ну ты же сам тут же делаешь оговорку. Чем DSL для разработки компиляторов хуже, чем DSL для описания фильтров для фотошопа?

Если отвлечься от специфики, то окажется, что у любого языка есть какой-то домен.
Бытовое понятие "языка общего назначения" обычно просто означает повышенную "ширину" домена, по сравнению с каким-то другим доменом.
Ну, вот скажем, HP-GL, вроде бы, бесспорно DSL. Он не тьюринг-полный, да и вообще плохо напоминает язык программирования.

А вот, скажем, ECMAScript — это ЯОН? Однозначно ЯОН.
Но в его синтаксис встроена специальная поддержка для regex-ов, что заставляет задуматься над "несимметричностью" его домена.

Или вот, скажем, фортран — это ЯОН? Судя по обилию произвольных программ, написанных на нём (скажем, бухгалтерию на нём в до-одинэсные времена писали — только в путь), он вполне себе ЯОН.
Но наличие в нём встроенного типа для комплексных чисел и всей нужной арифметики подсказывает нам, что разрабатывался он всё-таки для вычислительной математики.

В С++ нет встроенного типа complex. Зато есть возможность ввести его, и получить вполне приличный синтаксис. Грубо говоря, С++ — это язык для разработки кастомной арифметики. Вы посмотрите, сколько в нём любовного внимания уделено перегрузке операторов и тонкостям передачи данных "по значению". Бьярни явно хотелось порвать Фортран путём разработки движка для промышленного выпуска Фортранов. Зато вот строки в плюсах — бедный родственник (что по-прежнему лучше фортрана, в котором строки были прямо-таки чужаками). Видно, что авторы языка не хотели, чтобы на нём кто-то работал с текстами.

В итоге мы всё равно упираемся в сравнение тёплого с мягким. "Уровень" С++ в одних местах "выше", чем у С# 1.0 (позволяя описывать шаблонные функции и типы), а в других — "ниже" (требуя вручную управлять динамически распределённой памятью).
"Ширина" домена тоже штука плохо — домены могут пересекаться лишь частично, и непонятно, в ком из сравниваемых чего-то "не хватает".

И тем не менее, на бытовом уровне мы всё ещё можем сравнивать языки между собой, пусть и нечётко. Заголовок топика, хоть и крайне провокационный, всё же несёт здравое зерно.

На мой взгляд, оно как раз в стоимости разработки языков. Ну, то есть понятно, что исторически первыми появлялись именно DSL — фортран, алгол. Языки общего назначения были попыткой сэкономить на разработке и изучении множества DSL (помните Аду?).
Если посмотреть на то, с чем мы вышли из 80х, то в списке популярных мы будем иметь два языка, разработанных чисто для обучения (Pascal и Basic), два DSL, выросших в GPPL (Фортран и C), и C++.
В течение 30 лет народ тщательно пилил ЯОНы, пытаясь довести их до совершенства. Главная идея развития: давайте дадим возможность пилить библиотеки, и паническая боязнь встроить в язык хоть что-то конкретное. Надо полагать, всех пугала тень Ады. "Если дать человеку тип "строка", он проживёт один день. Если дать ему механизм реализации пользовательских типов строк и перегрузки операций, то он протрахается всю жизнь".
В 2000х пошла некоторая обратная тенденция: вместо механизмов по построению механизмов по решению задач, стало можно потихонечку внедрять просто механизмы по решению задач. Т.е. вносить некоторую доменную специфику.

В принципе, никто не будет спорить, что обжать разъём RJ-45 лучше при помощи обжимочного инструмента. Что заворачивать шурупы удобнее шуруповёртом, чем отвёрткой, и чем даже дрелью.
Есть подозрение, что если бы у нас был дешёвый способ клепать высококачественные языки для решения конкретных типов задач, то вряд ли бы мы стали от него отказываться, и стараться решить всё многословно, коряво, но зато на "универсальном" языке.

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

G>В бизнесе чуть ли не все задачи типовые, но вот dsl для них не придумали.
Простите, вы не BPEL, случайно, ищете?

Здравствуйте, WolfHound, Вы писали:
S>>Не, это ужасный синтаксис. Надо копать ещё дальше.
WH>Я не про синтаксис. А про то, что нужно свести все к этим операциям.
А, ну так состав операций никак не изменился.
Вообще, все нужные операции уже давно описаны Коддом.
Проблема SQL — только в том, что в нём нет понятия "функция" в широком смысле. И тем более нет понятия "функция высшего порядка".

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

S>Есть подозрение, что если бы у нас был дешёвый способ клепать высококачественные языки для решения конкретных типов задач, то вряд ли бы мы стали от него отказываться, и стараться решить всё многословно, коряво, но зато на "универсальном" языке.

Так есть он, этот способ. Причем мало от языка зависящий.

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

G>>В чем проблема?
WH>В том, что бизнес задачами занимаются люди, которые дальше языков общего назначения ничего не видят.

Других просто нет.

WH>Вот ты, например даже не задумаешься о том, что можно сделать ДСЛ.
WH>И в институтах этому не учат. И вообще распространяют миф, что это что-то очень сложное.

Враньё. Курс вроде компиляторов есть почти во всех серьехзных ИТ-вузах. Из своих наблюдений
1. большинство программистов плохо знает математику
2. компиляторы хорошо идут только у тех кто хорошо знает математику

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

WH>>В том, что бизнес задачами занимаются люди, которые дальше языков общего назначения ничего не видят.

T>Других просто нет.

Да все и везде одинаковые. Просто этим не объяснили, куда и как смотреть.

T>Враньё. Курс вроде компиляторов есть почти во всех серьехзных ИТ-вузах. Из своих наблюдений

Есть. Плохой, паршивый курс. Драконовщина везде царит.

T>1. большинство программистов плохо знает математику

И пусть себе. Не беда.

T>2. компиляторы хорошо идут только у тех кто хорошо знает математику

У меня хорошо идут. Математику не знаю и не люблю.

Здравствуйте, Serginio1, Вы писали:
S>>Непонятна семантика — тут нет опечаток? Если нету, то что имеется в виду под aTable и e — это типа "переменные"?
S>>Чего хочется получить?
S> Видно под extended имеется ввиду подчиненная таблица как в ObjectQuery
Как раз это — сахар чистой воды.
Замена

select * from Person p 
  where p.City.Name like 'Ново%'

на

select p.* from Person p 
inner join City on p.City = City.Id
  where City.Name like 'Ново%'

Во-первых, тривиальна, во-вторых, не очень много чего экономит. Ну, то есть в развесистых star-join запросах это было бы полезно, но реальный пауэр — это всё же возможность полноценной функциональной декомпозиции. Хотя бы без ФВП.
Без этого 3/4 хранимых процедур в реальных SQL базах — это ужасный boilerplate, который существует исключительно из-за невозможности повторного использования. Все вот эти "where ((startDate >= @minDate or @minDate is null) and (startDate <= @maxDate or @maxDate is null)) or ((endDate >= @minDate or @minDate is null) and (endDate <= @maxDate or @maxDate is null)) и прочий тихий ужос. Это на уровне кортежей. На уровне реляций всё ещё хуже — нет никакой возможности написать универсальную функцию, всё всегда только по месту.

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

O> Так есть он, этот способ. Причем мало от языка зависящий.
Расскажите.

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

G>>У меня как раз был курс построения языков и мы там dsl рассматривали. Именно оттуда я выяснил что это сложная тема.
G>>Ты считаешь по-другому, можешь обосновать?
WH>1)В институте плохому учат. У них там все действительно сложнее, чем надо получается.
WH>2)Сложность рукопашного кода всё равно больше. Чем сложность компилятора.

Не нужно передергивать.
"Сложность рукопашного кода всё равно больше" — для каких задач ?
Всегда ли нужно писать полноценное решение ?

На примере CSV-парсера. В разных проектах, в которые пришлось сунуть нос, видел уже наверное под сотню парсеров, от простых вроде string.split до всяких регулярных выражений и тд. Работают все по разному, с разной степенью надежности, производительности и тд.
1 Покажи на примере этой простой задачи преимущества DSL.
2 Всегда ли нужно писать полноценный парсер вроде CSV ?
3 Объясни, кем заменить тех, кто не в состоянии написать чтото большее string.split ?

DSL, хочешь ты или нет, это очень сложная тема. Очевиднл, рукапашный код будет еще сложнее, но сложности задачи это не отменяет. Если люди способны работать на продакшн и могут писать вроде string.split, то нужно предложить хорошую замену задирая планку требований до небес.

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

T>3 Объясни, кем заменить тех, кто не в состоянии написать чтото большее string.split ?

Я бы рассказал, что надо сделать с теми, кто выдумывает форматы, требующие чего-то большего чем String.Split. CSV это злобно и бесчеловечно.

T>DSL, хочешь ты или нет, это очень сложная тема.

Не-а. Простая. Проще некуда.

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

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

G>>Чтобы написать в 10 раз меньше надо сначала написать DSL, что сложнее чем написать код. Ты пока что обратного не смог показать.
WH>Смех на палочке.
WH>Напиши этот код руками:
... мусор убрал
WH>Любому непредвзятому человеку ясно, какой вариант выбрать.

Это передергивание. Пока ты дошел до этого, ты сотни раз писал вские парсеры, грамматики и тд и тд и тд. То есть, ты уже написал под сотню другую вариантов и твой коротенький код есть результат всех этих попыток.
Осталось дело за малым — распространить твой опыт на индустрию. Всего то посадить по WolfHound на каждый проект

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

T>Это передергивание. Пока ты дошел до этого, ты сотни раз писал вские парсеры, грамматики и тд и тд и тд. То есть, ты уже написал под сотню другую вариантов и твой коротенький код есть результат всех этих попыток.

Достаточно один раз написать, чтобы понять. Не велика проблема. Это как "hello, world".

Да и не в парсерах дело, они весьма редко нужны. DSL это не обязательно новый синтаксис.

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

Поверь мне пушущему на 1С этих соединений в запросе может быть великое множество, так что доступ через точку резко сокращает и главное улучшает читаемость кода.
А так полностью согласен.

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

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

G>>В бизнесе чуть ли не все задачи типовые, но вот dsl для них не придумали.
S>Простите, вы не BPEL, случайно, ищете?

BPEL — очень высокий уровень. Проблемы как раз уровнем ниже начинаются.

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

ANS>>Имя таблицы захардкожено.
S>Нет, никуда ничего не захардкожено. SearchPerson всё равно, какую таблицу ей дадут. В идеале всё должно быть "переменной" — и 'FirstName, LastName', и 'SearchPerson', и 'Employees', и 'John'. Но хотя бы так.

Это я не правильно сказал. И пример мой — дурацкий. Забудь
Я думал о рефлексии. Тогда всё действительно сводится к тому, что не хватает relation, как первоклассной сущности.
С другой стороны особенность SQL такова, что без хост-языка он смысла не имеет. А подзапросы мне по прежнему кажутся достаточными для декомпозиции.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Я думал о рефлексии. Тогда всё действительно сводится к тому, что не хватает relation, как первоклассной сущности.
relation как первоклассная сущность в SQL есть. Нет функций как первоклассной сущности.
ANS>С другой стороны особенность SQL такова, что без хост-языка он смысла не имеет. А подзапросы мне по прежнему кажутся достаточными для декомпозиции.
Откуда такие иллюзии? Я показал примеры декомпозиции, которые невозможны на SQL. Вам что-то непонятно? Спрашивайте.
Подзапросы не спасут вас от монолитности запроса — это всего лишь те же шесть страниц, записанные в другом порядке.

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

VD>>На то она и предметная область, чтобы решать только ее задачу. Если ДСЛ позволяет (пусть криво или медленно) воспроизвести себя, то это ЯОН (язык общего назначения). А его уровень не имеет никакого отношения к ДСЛ-ности.
WH>Плохой критерий.
WH>Ибо так умеют все полные по Тьюрингу языки.

Не все. Для этого еще доступ к внешним ресурсам нужен.

WH>Соответственно если вдруг ДСЛ окажется полным по Тьюрингу, то он сразу перестает быть ДСЛ?

В общем — да. Как только язык становится универсальным, то он перестает быть ДСЛ-ем. Он становится специализированным (или не очень) ЯОН.

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

S>Влад, я с этим не согласен. Ну ты же сам тут же делаешь оговорку. Чем DSL для разработки компиляторов хуже, чем DSL для описания фильтров для фотошопа?

Ничем. Но ДСЛ для фильров не должен позволять написать ДСЛ для фильтров, а только фильтры.

S>Если отвлечься от специфики, то окажется, что у любого языка есть какой-то домен.
S>Бытовое понятие "языка общего назначения" обычно просто означает повышенную "ширину" домена, по сравнению с каким-то другим доменом.

Это бессмысленная философия. Должно быть различие между двумя совершенно разными вещами.
* языком на котором можно написать все, что угодно, но тем или иным образом используемым для решения некой задачи;
* и языком предназначенным для решения конкретной задачи и только ее.

Если такого различия не будет, то и говорить ДСЛ-ях будет невозможно, так как у дей будет каша в голове.
Уж слишком разные требования и свойства у этих вещей.

Кроме того тогда встает вопрс о том, что вместо ДСЛ можно использовать термин "язык". Ведь если мы дофилософствовались до того, что любой язык являетс ДС, то нафиг тогда нужна эта приставка?

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

VD>Ничем. Но ДСЛ для фильров не должен позволять написать ДСЛ для фильтров, а только фильтры.
Ну, а язык для компиляторов не обязан позволять написать фильтр. Или, по крайней мере, написать его удобно (понятно, что любой тьюринг-полный язык сразу даст написать и фильтр, и компилятор с DSL).

VD>Это бессмысленная философия. Должно быть различие между двумя совершенно разными вещами.
Развернём утверждение: если чёткого различия нет, то две вещи не являются совершенно разными. Не так ли?

VD>* языком на котором можно написать все, что угодно, но тем или иным образом используемым для решения некой задачи;
VD>* и языком предназначенным для решения конкретной задачи и только ее.
Мне кажется, ты сравниваешь полноту по тьюрингу с проблемно-ориенированностью.
На мой взгляд, они не являются взаимоисключающими.

VD>Уж слишком разные требования и свойства у этих вещей.
Не вижу особенных различий в требованиях. Вот, скажем, два языка — Паскаль и C++. Оба — GPPL ("можно написать все, что угодно"). Но в Паскале есть встроенная механика по работе с файлами фиксированной структуры (FILE OF TYPE), а С++ — механика перегрузки операторов. Почему? Надо полагать, у них отличаются домены.

VD>Кроме того тогда встает вопрс о том, что вместо ДСЛ можно использовать термин "язык". Ведь если мы дофилософствовались до того, что любой язык являетс ДС, то нафиг тогда нужна эта приставка?
Влад, с какого момента можно называть человека толстым? Где граница между "полным", "полноватым", и "склонным к полноте"?