Здравствуйте, WolfHound, Вы писали:
W>>То-то же N так и не разродился промышленным компилятором... WH>Так это по тому, что при его реализации не использованы ДСЛ.
И не сможете их использовать как следует до тех пор, пока для каждого макроса нужно отдельную DLL делать. Не получатся многоуровневые макроопределения (т.е., макросы, раскрывающиеся в определения макросов, которые тут же и используются). Учитесь у common lisp.
Здравствуйте, WolfHound, Вы писали:
WH>Вот только он не это сказал. WH>Он сказал, что ДСЛ нужны только не программистам и в основе полезных ДСЛ нет матана. WH>Читай то, что написано, а не то, что ты хочешь прочитать.
Да, мне раза три перечитать пришлось. Вижу, что был не прав.
Здравствуйте, WolfHound, Вы писали:
O>>Кстати, почему не packrat? Он туп как пробка, и тем прекрасен? WH>1)Не смотря на линейность, он жуткий тормоз.
Там огромный простор для оптимизаций. Да и тормоз он если backtracking глубокий. Для большинства человечных, добрых, простых грамматик этого просто не должно случаться.
WH>2)Задолбаешься задавать приоритеты операторам. А ассоциативность ПЕГ вообще не может.
Как это не может? Как это задолбаюсь?
term = fact '+' term / fact '-' term / fact;
fact = atom '*' fact / atom '/' fact / atom;
Приоритеты очевидны, никто не задолбался. Ассоциативность получаем, если добавим левую рекурсию (http://www.vpri.org/pdf/tr2007002_packrat.pdf)
WH>3)У ПЕГ есть проблема с приоритетным выбором. Его очень сложно использовать.
Как раз наоборот! Приоритетный выбор очевиден для простого смертного, не испорченного yacc-ами. А вот BNF как раз неочевиден и рождает неоднозначные конфликты.
WH>4)ПЕГ в чистом виде не поддерживает изменение грамматики во время разбора.
Это крайне легко исправляется, как раз в силу вашего следующего пункта:
WH>5)У ПЕГ низкая декларативность. Фактически приходится описывать алгоритм разбора.
И это прекрасно! Для не испорченных теорией программистов, каких большинство, это как раз наилучший баланс. Это как раз тот случай, когда полезно понимать, что за код генерится, и иметь возможность в любой момент откатиться на уровень ниже и что-то там недекларативное сделать. Как результат — получаем сколь угодно умные и уместные сообщения об ошибках, получаем возможность делать грязные хаки для грамматик вроде C++, и много чего еще. С чисто декларативными yacc-ами такой фокус не пройдет.
WH>Поэтому был разработан новый алгоритм. За основу были взяты PEG и Pratt parser.
И отброшена мемоизация? Зря. Для того же syntax highlighting и для реализации левой рекурсии это мощнейшая штука.
WH>Ну да. Парсер должен описываться очень просто. WH>Но современные инструменты не адекватны.
У меня не бывает проблем даже при написании парсеров на примитивных низкоуровневых языках вроде C. Где там неадекватность-то?
WH>На том же ПЕГ это сделать очень не просто. Особенно если у тебя есть несколько операторов с разными приоритетами и ассоциативностью.
Никогда не встречался с трудностями с приоритетами и ассоциативностью, все элементарно и прозрачно.
O>>Сейчас даже на голом шарпе без сторонних библиотек dslы делать легко и приятно. Да что там, я их когда-то и на Фортране писал не включая мозга. WH>Какие ДСЛи?
Языки запросов, конфигурации (Тьюринг-полные, увы, не моя вина), внутренние языки для представления данных, и много чего еще.
Здравствуйте, VladD2, Вы писали: VD>Создание ДСЛ не будет бесплатным никогда! Ни какие N256 не устранят необходимости выделять модель, придумывать язык для ее описания и манипуляций с ней, реализовывать язык и т.п.
Решение любой задачи вообще всегда сводится к созданию языка. Всегда. Достаточно заметить этот факт, и дальше все становится просто.
Посмотрите на историю развития науки. Каждая новая теория это язык. Каждая хоть немного новая и сложная задача решается через введение нового языка. Вся математика это не более чем коллекция разнообразных языков, созданных в разное время для решения возникающих в науке задач.
Инженерные задачи тут ничем не отличаются, а программирование это задача инженерная.
VD>Все что можно сделать сократить затраты на такую разработку. Но все равно будет сто тысяч задач которые проще решить в лоб, нежели писать для нее ДСЛ в стиле "Решим мне мою проблему".
Решение "в лоб" тоже всегда сводится к созданию языка. Просто в большинстве случаев это недостаточно очевидно, и если узко мыслить в терминах существующих языков то можно не заметиь, что родился новый язык.
Здравствуйте, oldjackal, Вы писали:
WH>>Вот только он не это сказал. WH>>Он сказал, что ДСЛ нужны только не программистам и в основе полезных ДСЛ нет матана. WH>>Читай то, что написано, а не то, что ты хочешь прочитать. O> Да, мне раза три перечитать пришлось. Вижу, что был не прав.
В этом и есть единственный талант данного персонажа.
Он умеет говорить бред, так что у окружающих создается впечатление, что он сказал что-то умное.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sinclair, Вы писали:
V>>Речь то как раз про удобные и несложные средства. SQL на них не тянет, т.к. является таким же тяжёлым языком как языки общего назначения. S>Не понимаю, откуда такой вывод. SQL является удобным и несложным средством описания сложных операций с данными. Если все ваши операции с данными — это локальные load и save, то SQL вам не нужен. S>А если вам нужно посчитать какие-то агрегаты по результату join восьми таблиц, и при этом ещё иметь гарантии ACID, то вручную вы это делать замаетесь.
Ну что вы мне сказки рассказываете? Специалист по SQL это такой же специалист по C++ или java, а это самостоятельные языки.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, VladD2, Вы писали:
VD>Лично для меня очевидно, что ДСЛ дающий делать больше чем нужно для решения задачи предметной области — это как минимум плохой ДСЛ. А скорее всего не ДСЛ.
Если нет инфраструктуры для взаимодействия множества разных DSL, то это не плохо, это необходимость.
Если это встраиваемый DSL, тогда да, тогда это просто протекающая абстракция и за такое надо наказывать.
VD>Польза ДСЛ в декларативности описания.
Ну вот зачем так ограничивать возможности DSL? Почему обязательно "декларативность"? DSL могут быть какими угодно, и в этом их сила. Единственное требование к DSL это умение разговаривать в терминах предметной области и отсутствие необходимости ритуальных действий, к предметной области отношения не имеющих.
VD>Если библиотека решает задачу на достойном уровне, то ДСЛ — оверкил. VD>Зачем не вводить новый синтаксис для чтения содержимого текстового файла, если это же я могу сделать вызвав библиотечную функцию?
А DSL это вовсе не обязательно новый синтаксис. И даже тупая Java-библиотека может быть полноценным DSL (любители OOP не зря так носятся с interpreter pattern).
VD>Смысл в ДСЛ-е появляется тогда, когда библиотечная функция: VD>* Не может выразить решение задачи без копипасты и кучи ручного кодирования. VD>* Приводит к более медленному решению. VD>* Выливается в эмуляцию ДСЛ-я средствами ЯОН.
Это все не важно. DSL должен использоваться тогда, когда между решением и предметной областью встает язык, примешивая туда свои нерелевантные сущности (переменные там всякие, циклы и прочую, далекую от модели реальности чушь). Только вот синтаксис новый вводить совершенно не обязательно, такого эффекта можно добиться подбором API библиотеки. Если язык позволяет использовать функции высшего порядка, если в языке есть карринг, то "библиотечные" DSL делать легко и просто, у тех же хаскеллистов этот метод общепринят. Но даже в обычном ООП-языке можно такие трюки исполнять, с чуть большим количеством синтаксического мусора.
VD>Да ты уже немного заколебал этой мантрой для домен языка. Домен любого ЯОН — написание функций. И спопитсот задач может быть отлично выражены в виде функции.
Ну, это несколько неверно. Даже я бы сказал абсолютно неверно. Домен языков общего назначения — моделирование поведения "реального" железа. Семантика этих языков так или иначе сводится к семантике вычислений Фон-Неймановских железок. И ценность этих языков как раз в том, чтобы быть промежуточным звеном между высокооабстрактыми семантиками предметных областей, далеких по сути от вычислений, и собственно железом, без которого во всем этом не было бы смысла. Так что "общее" их назначение существенно преувеличенно.
VD>А вот ДСЛ может быть нежелателен хотя бы потому, что время затраченное на него больше лобового решения. Или его тупо сложно выделить.
Выделить DSL можно всегда, это естественный результат решения любой задачи.
Здравствуйте, oldjackal, Вы писали:
O> И не сможете их использовать как следует до тех пор, пока для каждого макроса нужно отдельную DLL делать.
Это не проблема.
Проблемы Н1 в очень плохой архитектуре.
O>Не получатся многоуровневые макроопределения (т.е., макросы, раскрывающиеся в определения макросов, которые тут же и используются).
В Н2 не будет никаких проблем сделать иерархию языков.
O>Учитесь у common lisp.
Я вижу это решение несколько иначе.
Н2 будет полностью типизировать всю программу.
После чего будут применены несколько трансформаций каждая, из которых будет переписывать язык в более низкоуровневый.
И тут нет никаких проблем с тем, чтобы разложить их по разным ДЛЛ.
Я даже куски грамматики научился по разным ДЛЛ раскидывать. Это уже работает.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
O>> И не сможете их использовать как следует до тех пор, пока для каждого макроса нужно отдельную DLL делать. WH>Это не проблема.
Ну как же? Макрос, определенный в модуле, не может в том же модуле использоваться. Это очень плохо. По этой причине я Nemerle и забросил, хотя в остальном язык показался весьма интересным.
WH>Проблемы Н1 в очень плохой архитектуре.
Внутрь не смотрел, не в курсе. Поверю на слово.
O>>Не получатся многоуровневые макроопределения (т.е., макросы, раскрывающиеся в определения макросов, которые тут же и используются). WH>В Н2 не будет никаких проблем сделать иерархию языков.
Т.е., можно будет пользоваться макросом сразу после определния? А lexically scoped макросы будут?
O>>Учитесь у common lisp. WH>Я вижу это решение несколько иначе. WH>Н2 будет полностью типизировать всю программу.
Тогда каждый макрос придется делать из двух частей; одна будет разруливать типизацию до раскрытия всех внутренностей, а вторая разворачивать AST.
Так, конечно же, можно делать, но могут вылезти некоторые занятные сложности.
WH>После чего будут применены несколько трансформаций каждая, из которых будет переписывать язык в более низкоуровневый.
Только "несколько"? Или ровно столько, сколько нужно для раскрытия всех вложенных макросов?
WH>И тут нет никаких проблем с тем, чтобы разложить их по разным ДЛЛ.
Да не надо вообще этих dll! В Common Lisp один общий, постоянно растущий image, где и макросы и все прочее. И это удобно.
WH>Я даже куски грамматики научился по разным ДЛЛ раскидывать. Это уже работает.
Раскидывать не интересно. А вот определить и в том же модуле воспользоваться, это было бы полезно и удобно.
Здравствуйте, oldjackal, Вы писали:
O> Там огромный простор для оптимизаций. Да и тормоз он если backtracking глубокий. Для большинства человечных, добрых, простых грамматик этого просто не должно случаться.
В packrat нет откатов. Он гарантированно линейный.
В этом его главная фича.
Проблема в том, что мемоизация жрет времени больше чем экономит.
Прочитай про тот же Rats! Самые сильные оптимизации это убирание мемоизации.
Я во время своих экспериментов пришёл к тем же выводам. В результате мемоизация у меня весьма своеобразная.
WH>>2)Задолбаешься задавать приоритеты операторам. А ассоциативность ПЕГ вообще не может. O> Как это не может? Как это задолбаюсь? O>
O> term = fact '+' term / fact '-' term / fact;
O> fact = atom '*' fact / atom '/' fact / atom;
O>
Добавь между ними еще один оператор.
И сравни с этим:
[StartRule, Ast()]
expr : Ast;
[Ast(l, expr, r)] rounds is expr = '('s expr ')'s;
[Ast(l, expr, r)] seq is expr = '{'s expr* '}'s;
[Ast(num)] num is expr = number s;
[Ast(op, expr)] neg is expr = '-'s expr : 100;
[Ast(op, expr)] prefixDec is expr = "--"s expr : 200;
[Ast(expr, op)] postfixDec is expr = expr : 200 "--"s;
[Ast(l, op, r)] add is expr = expr : 10 '+'s expr : 10;
[Ast(l, op, r)] sub is expr = expr : 10 '-'s expr : 10;
[Ast(l, op, r)] mul is expr = expr : 20 '*'s expr : 20;
[Ast(l, op, r)] div is expr = expr : 20 '/'s expr : 20;
[Ast(l, op, r)] mod is expr = expr : 20 '%'s expr : 20;
[Ast(l, op, r)] pow is expr = expr : 31 '^'s expr : 30;
В будущем я избавлюсь от цифр, и буду задавать приоритеты именами, для которых задан порядок.
Правая ассациотивность в данном случае делается элементарно.
expr : 31 '^'s expr : 30;
Причем алгоритм линеен без всякой мемоизации.
O> Приоритеты очевидны, никто не задолбался. Ассоциативность получаем, если добавим левую рекурсию (http://www.vpri.org/pdf/tr2007002_packrat.pdf)
Это уже не пакрат. И даже не ПЕГ. Ибо семантика языка уже изменена.
Плюс у меня есть требование изменение грамматики во время разбора.
Твой вариант в этом случае вообще никак не работает.
O> Как раз наоборот! Приоритетный выбор очевиден для простого смертного, не испорченного yacc-ами.
Практика показала, что на сложных грамматиках люди не могут адекватно его использовать.
Вот, например: https://github.com/rsdn/nemerle/blob/master/snippets/csharp-parser/CSharpParser/Parser.n
В этой грамматике есть несколько ошибок связанных с приоритетным выбором.
Попробуй найди.
O>А вот BNF как раз неочевиден и рождает неоднозначные конфликты.
Проблемы БНФ в другом месте.
Он не работает по тому, что БНФ это порождающая грамматика. А нам нужно разбирать текст.
Из-за этого несоответствия и получаются все эти проблемы.
O> И отброшена мемоизация? Зря. Для того же syntax highlighting и для реализации левой рекурсии это мощнейшая штука.
У меня левая рекурсия работает иначе.
O> У меня не бывает проблем даже при написании парсеров на примитивных низкоуровневых языках вроде C. Где там неадекватность-то?
Ты тут сам про проблемы яков говорил. И они фундаментальны. Ибо БНФ грамматика порождающая.
Причем восходящие парсеры (всё семейство LR) вообще не могут выдать адекватные сообщения об ошибках. Ибо разбирают текст не в том порядке, в котором его разбирает человек.
Поэтому парсеры нужно делать на основе разбирающих грамматик основанных на нисходящем разборе.
O> Никогда не встречался с трудностями с приоритетами и ассоциативностью, все элементарно и прозрачно.
Ты, может быть, и нет.
Но! Ты нерепрезентативен. (С)одна из поговорок Яндекса
Честно говоря, я не хочу обсуждать этот вопрос.
ПЕГ я уже отработал. Даже генератор ПЕГ парсеров написал. https://github.com/rsdn/nemerle/tree/master/snippets/peg-parser
И на анализе практики его использования, а так же попыток придумать динамическую расширяемость я и сделал свои выводы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, oldjackal, Вы писали:
O> Ну как же?
Ну вот так.
O>Макрос, определенный в модуле, не может в том же модуле использоваться. Это очень плохо. По этой причине я Nemerle и забросил, хотя в остальном язык показался весьма интересным.
Макрос это простая функция, которая берет несколько кусков АСТ и возвращает новое.
Рекурсивным функциям ДЛЛ не мешают.
O> Т.е., можно будет пользоваться макросом сразу после определния? А lexically scoped макросы будут?
Не совсем.
Тут другая идеология.
Так просто не напишешь. А писать большую статью я пока не готов.
O> Тогда каждый макрос придется делать из двух частей; одна будет разруливать типизацию до раскрытия всех внутренностей, а вторая разворачивать AST.
Именно. Причем типизация будет полностью декларативна. Я уже и матаном на эту тему обчитался.
O> Так, конечно же, можно делать, но могут вылезти некоторые занятные сложности.
Например? Влад тоже об этом долго говорил, но продемонстрировать не смог.
O> Только "несколько"? Или ровно столько, сколько нужно для раскрытия всех вложенных макросов?
Столько сколько нужно.
O> Да не надо вообще этих dll! В Common Lisp один общий, постоянно растущий image, где и макросы и все прочее. И это удобно.
У меня другое мнение.
Тем более что подход лиспа не канает просто по тому, что он динамически типизирован.
А я динамическую типизацию считаю ошибкой природы.
Тормозит, жрет память и главное ошибки не ловит.
O> Раскидывать не интересно. А вот определить и в том же модуле воспользоваться, это было бы полезно и удобно.
У меня просто другой подход. Он не хуже чем лисп. Просто другой.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
O>> Там огромный простор для оптимизаций. Да и тормоз он если backtracking глубокий. Для большинства человечных, добрых, простых грамматик этого просто не должно случаться. WH>В packrat нет откатов. Он гарантированно линейный.
Не так просто. Откаты есть (backtracking бесконечный), но он линейный за счет мемоизации.
WH>В этом его главная фича. WH>Проблема в том, что мемоизация жрет времени больше чем экономит.
Зависит от реализации мемоизации.
WH>Прочитай про тот же Rats! Самые сильные оптимизации это убирание мемоизации.
Естественно. Не все термы запоминать надо. И не в таблице, а в списке, что несколько убивает линейность но в разы сокращает константный коэффициент при O(1).
WH>Я во время своих экспериментов пришёл к тем же выводам. В результате мемоизация у меня весьма своеобразная.
Но таки есть мемоизация?
WH>>>2)Задолбаешься задавать приоритеты операторам. А ассоциативность ПЕГ вообще не может. O>> Как это не может? Как это задолбаюсь? O>>
O>> term = fact '+' term / fact '-' term / fact;
O>> fact = atom '*' fact / atom '/' fact / atom;
O>>
WH>Добавь между ними еще один оператор.
[code]
term = fact '+' term / fact '-' term / fact;
fact1 = atom '*' fact1 / atom '/' fact1 / atom;
term = fact1 '$' term / fact1;
[code]
Добавил. Не задолбался.
Кстати, авторам грамматик со сложной, многоуровневой системой приоритетов, вылезающей за пределы привычной со школы арифметики, надо отрубать руки. За садизм и бесчеловечность. Больше трех уровней это уже садизм и мизантропия.
WH>И сравни с этим:
А вот числовые приоритеты как раз для восприятия сложнее. Это их еще сравнивать надо, а тут тупо список, те что пониже приоритетом идут вперед, что повыше в конце.
WH>В будущем я избавлюсь от цифр, и буду задавать приоритеты именами, для которых задан порядок.
Это уже лучше, но все равно требует напряжения мозгов у читающего.
WH>Правая ассациотивность в данном случае делается элементарно. WH>expr : 31 '^'s expr : 30; WH>Причем алгоритм линеен без всякой мемоизации.
Правая то и так без мемоизации получается. Левая интереснее.
O>> Приоритеты очевидны, никто не задолбался. Ассоциативность получаем, если добавим левую рекурсию (http://www.vpri.org/pdf/tr2007002_packrat.pdf) WH>Это уже не пакрат. И даже не ПЕГ. Ибо семантика языка уже изменена.
Ну почему же? Packrat с наворотами. Причем только там, где есть левая рекурсия, в остальном тот же packrat.
WH>Плюс у меня есть требование изменение грамматики во время разбора. WH>Твой вариант в этом случае вообще никак не работает.
Работает. Единственное ограничение — нельзя леворекурсивые правила добавлять в нелеворекурсивные. Это если мы их оптимизируем. Если нет — то можно, не проблема.
O>> Как раз наоборот! Приоритетный выбор очевиден для простого смертного, не испорченного yacc-ами. WH>Практика показала, что на сложных грамматиках люди не могут адекватно его использовать.
Если кто-то попробует сделать DSL с синтаксисом шарпа, то ему надо отрубить обе руки. За садизм и бесчеловечность. Потом и документацию на тысячу страниц писать, с описанием тонкостей приоритетов операторов?
O>> И отброшена мемоизация? Зря. Для того же syntax highlighting и для реализации левой рекурсии это мощнейшая штука. WH>У меня левая рекурсия работает иначе.
Но работает? Это хорошо. А как насчет highlighting? Можно распарсить только измененный регион текста, без мемоизации?
O>> У меня не бывает проблем даже при написании парсеров на примитивных низкоуровневых языках вроде C. Где там неадекватность-то? WH>Ты тут сам про проблемы яков говорил. И они фундаментальны. Ибо БНФ грамматика порождающая.
Так я без якков. Руками. Ad hoc в самом махровейшем виде.
WH>Поэтому парсеры нужно делать на основе разбирающих грамматик основанных на нисходящем разборе.
Естественно. И даже так полно исключительных случаев, когда надо ругнуться более умно, чем любой генератор парсеров позволит. Как в clang, например — "а не забыли ли вы скобки вокруг параметров оператора &&? точно-точно?"
O>> Никогда не встречался с трудностями с приоритетами и ассоциативностью, все элементарно и прозрачно. WH>Ты, может быть, и нет. WH>Но! Ты нерепрезентативен. (С)одна из поговорок Яндекса
Я репрезентативен, я как любой человек, осознающий свою ограниченность, не лезу в сложные грамматики. Мне хватает простых. А сложные грамматики придумывают всякие злобные теоретики из комитетов, простым людям с ними не по пути. Я не хочу парсить шарп или плюсы, я хочу парсить Pascal или Oberon.
WH>https://github.com/rsdn/nemerle/tree/master/snippets/peg-parser
Посмотрю.
WH>И на анализе практики его использования, а так же попыток придумать динамическую расширяемость я и сделал свои выводы.
Так что не так-то с динамической расширяемостью? Чем меньше декларативности, тем ее проще реализовывать, разве нет?
Здравствуйте, Vain, Вы писали: S>>А если вам нужно посчитать какие-то агрегаты по результату join восьми таблиц, и при этом ещё иметь гарантии ACID, то вручную вы это делать замаетесь. V>Ну что вы мне сказки рассказываете? Специалист по SQL это такой же специалист по C++ или java, а это самостоятельные языки.
Я не понял вашу фразу.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, WolfHound, Вы писали:
WH>На самом деле это тоже криво. WH>У тебя, по сути, меняются только имена таблиц. WH>Хороший язык должен иметь возможность свести это к чему-то типа такого. WH>[Employees, Customers, Contacts].Map(SearchPerson(_, 'John')).UnionAll().Select(FirstName, LastName);
Не, это ужасный синтаксис. Надо копать ещё дальше.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, WolfHound, Вы писали:
O>>Макрос, определенный в модуле, не может в том же модуле использоваться. Это очень плохо. По этой причине я Nemerle и забросил, хотя в остальном язык показался весьма интересным. WH>Макрос это простая функция, которая берет несколько кусков АСТ и возвращает новое. WH>Рекурсивным функциям ДЛЛ не мешают.
Ну так я смогу определить такую функцию и в том же модуле ей воспользоваться? А смогу из макроса воспользоваться другими функциями из этого модуля?
O>> Т.е., можно будет пользоваться макросом сразу после определния? А lexically scoped макросы будут? WH>Не совсем.
То есть, их не будет?
WH>Тут другая идеология.
Мне не нравятся идеологии с ограничениями. Любое ограничение должно быть обоснованно. Если мне запрещают ковыряться в носу, я хочу знать, за что такая несправедливость.
O>> Тогда каждый макрос придется делать из двух частей; одна будет разруливать типизацию до раскрытия всех внутренностей, а вторая разворачивать AST. WH>Именно. Причем типизация будет полностью декларативна. Я уже и матаном на эту тему обчитался.
Вот этого я и боюсь. Может получиться неприемлемо сложно.
O>> Так, конечно же, можно делать, но могут вылезти некоторые занятные сложности. WH>Например? Влад тоже об этом долго говорил, но продемонстрировать не смог.
Иногда типы могут зависеть от типизации вложенных макр, которых нет (и про которые мы ничего не знаем) до тех пор, пока AST не развернули. Когда я пытался прикрутить типизированную макросистему к ML я по этим граблям походил. В Nemerle система типов несколько более человечная, так что не берусь утверждать, что трудности непреодолимы.
O>> Только "несколько"? Или ровно столько, сколько нужно для раскрытия всех вложенных макросов? WH>Столько сколько нужно.
Ну хоть это радует.
O>> Да не надо вообще этих dll! В Common Lisp один общий, постоянно растущий image, где и макросы и все прочее. И это удобно. WH>У меня другое мнение.
Обоснуете? Чем плоха возможность пользоваться определениями сразу, не отходя от кассы?
WH>Тем более что подход лиспа не канает просто по тому, что он динамически типизирован.
Типизация то тут при чем? Не вижу вообще никакой связи. В том же ocaml есть REPL. Даже в Haskell он есть. А от REPL до инкрементальных макросов один шаг.
WH>А я динамическую типизацию считаю ошибкой природы. WH>Тормозит, жрет память и главное ошибки не ловит.
Ну, по этому вопросу лучше не дискутировать, у меня прямо противоположное мнение — я не хочу закрывать для себя возможности реализации вообще любой системы типов. Если же в языке уже есть строгая типизация, то она ограничивает возможные системы типов надстраиваемых над языком DSL.
O>> Раскидывать не интересно. А вот определить и в том же модуле воспользоваться, это было бы полезно и удобно. WH>У меня просто другой подход. Он не хуже чем лисп. Просто другой.
Пусть он другой, но если он ограничивает возможности реализации иерархических макросов, то он должен как минимум предоставлять что-то взамен. Что-то не менее ценное.
S>>select FirstName, LastName from SearchPerson(Employees, 'John')
S>>
ANS>Имя таблицы захардкожено.
Нет, никуда ничего не захардкожено. SearchPerson всё равно, какую таблицу ей дадут. В идеале всё должно быть "переменной" — и 'FirstName, LastName', и 'SearchPerson', и 'Employees', и 'John'. Но хотя бы так.
Всё таки, это просто синтаксический сахар. ANS>А вот то, что нельзя так сделать: ANS>
ANS>select
ANS> t.FirstName,
ANS> t.LastName,
ANS> (SELECT COUNT(*) FROM t.extended WHERE e.phone = t.phone)
ANS>from aTable t
ANS>
ANS>это ты прав.
Непонятна семантика — тут нет опечаток? Если нету, то что имеется в виду под aTable и e — это типа "переменные"?
Чего хочется получить?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали:
_>Попробую привести совсем упрощённый пример идеи. В стилистике Питона: _>
form Main
_> title "Main"
_> button Calc
_> title "Calc"
_> onclick [Calculate]
_> button About
_> title "About"
_> onclick About.ModalShow
_>form About
_> title "About"
_> button OK
_> title "OK"
_> onclick this.Close
_>
_>Это у нас будет файла нашего dsl. Компилируем его допустим в C++ h файл. И потом у нас останется написать реализацию функции Main::Calculate() на C++ в cpp файле и собрать итоговую программу.
_>P.S. Всё это придумал буквально 10 минут назад и вообще dsl строение не специалист, так что сильно не ругаете пример — это просто попытка подумать в сторону удобного gui dsl, отделяющего интерфейс программы от "движка".
Поздравляю, вы почти изобрели .dfm. Один-в-один. С точностью до способа группировки — индентация вместо явного object ... end.
Вы же только что критиковали "языки размётки", в которых "всего лишь привязываются обработчики, написанные на системном языке". И тут же делаете то же самое. Принципиальный момент, которого тут не хватает — согласование сигнатур. Грубо говоря, хорошо, когда у вас евенты без параметров, и методы без параметров.
Но это как раз неинтересно. Интересно, когда вам нужно передать данные из одного контрола или формы в другой. Вот коллега Wolfhound предлагает делать это через биндинги и ViewModel, а от событий (как я понял) отказаться вовсе.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, oldjackal, Вы писали:
WH>>Я во время своих экспериментов пришёл к тем же выводам. В результате мемоизация у меня весьма своеобразная. O> Но таки есть мемоизация?
Есть. Процентов 10 выжать удалось.
O>[code] O> term = fact '+' term / fact '-' term / fact; O> fact1 = atom '*' fact1 / atom '/' fact1 / atom; O> term = fact1 '$' term / fact1; O>[code] O> Добавил. Не задолбался.
Я знаю, как это делается.
Но меня данная операция всегда напрягала.
И что характерно всех моих знакомых тоже.
O> Кстати, авторам грамматик со сложной, многоуровневой системой приоритетов, вылезающей за пределы привычной со школы арифметики, надо отрубать руки. За садизм и бесчеловечность. Больше трех уровней это уже садизм и мизантропия.
Да я бы не сказал.
O> А вот числовые приоритеты как раз для восприятия сложнее. Это их еще сравнивать надо, а тут тупо список, те что пониже приоритетом идут вперед, что повыше в конце.
Не могу согласиться. Люди настолько привыкли к числам, что сравнивают их на больше/меньше не приходя в сознание.
WH>>В будущем я избавлюсь от цифр, и буду задавать приоритеты именами, для которых задан порядок. O> Это уже лучше, но все равно требует напряжения мозгов у читающего.
Это делается в основном для динамического расширения.
Чтобы человек всегда мог добавить новый приоритет.
O> Правая то и так без мемоизации получается. Левая интереснее.
У меня обе без мемоизации работают. Ключевые слова Pratt parser.
У меня алгоритм основа на нем.
O> Ну почему же? Packrat с наворотами. Причем только там, где есть левая рекурсия, в остальном тот же packrat.
Ну да. Выделенное уже меняет семантику ПЕГа. И формально это уже другой язык.
O> Работает. Единственное ограничение — нельзя леворекурсивые правила добавлять в нелеворекурсивные. Это если мы их оптимизируем. Если нет — то можно, не проблема.
А у меня ограничений нет. Все очень просто. Быстро. И линейно.
O> Практика прямо таки кричит, что сложных грамматик быть вообще не должно. Сколько можно C++-ы изобретать?
Да я не спорю. Но существующие языки тоже нужно разбирать.
O> Если кто-то попробует сделать DSL с синтаксисом шарпа, то ему надо отрубить обе руки. За садизм и бесчеловечность. Потом и документацию на тысячу страниц писать, с описанием тонкостей приоритетов операторов?
Описание приоритетов задается одной маленькой табличкой.
WH>>У меня левая рекурсия работает иначе. O> Но работает? Это хорошо.
Причем очень хорошо работает.
У меня алгоритм линейный даже без мемоизации.
O>А как насчет highlighting? Можно распарсить только измененный регион текста, без мемоизации?
Мне хватает скорости, чтобы все распарсить.
Но такое тоже со временем будет.
O> Естественно. И даже так полно исключительных случаев, когда надо ругнуться более умно, чем любой генератор парсеров позволит. Как в clang, например — "а не забыли ли вы скобки вокруг параметров оператора &&? точно-точно?"
Я это понимаю. И собираюсь сделать язык описания ошибочных ситуаций.
Это позволит очень просто задавать сообщения для подобных случаев.
O> Я репрезентативен,
Я о том, что далеко не всем людям понятно даже это: O>[code] O> term = fact '+' term / fact '-' term / fact; O> fact1 = atom '*' fact1 / atom '/' fact1 / atom; O> term = fact1 '$' term / fact1; O>[code]
Им гораздо проще задать приоритеты явно.
WH>>https://github.com/rsdn/nemerle/tree/master/snippets/peg-parser O> Посмотрю.
Да не на что там смотреть.
O> Так что не так-то с динамической расширяемостью? Чем меньше декларативности, тем ее проще реализовывать, разве нет?
Нет. Чем меньше декларативности, тем мутнее семантика языка.
Тем сложнее рассуждать о поведении грамматики при динамическом расширении.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
ANS>>select
ANS>> t.FirstName,
ANS>> t.LastName,
ANS>> (SELECT COUNT(*) FROM t.extended WHERE e.phone = t.phone)
ANS>>from aTable t
ANS>>
ANS>>это ты прав. S>Непонятна семантика — тут нет опечаток? Если нету, то что имеется в виду под aTable и e — это типа "переменные"? S>Чего хочется получить?
Видно под extended имеется ввиду подчиненная таблица как в ObjectQuery
string entitySQL = " SELECT p, p.Filling " +
"FROM PartyContext.Pinatas AS p "
"WHERE p.Filling.Description='Candy'";
var query=context.CreateQuery<DbDataRecord>(entitySQL);
query.MergeOption = System.Data.Objects.MergeOption.NoTracking;
var pinatasWithFilling=query.ToList();
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
S>Не, это ужасный синтаксис. Надо копать ещё дальше.
Я не про синтаксис. А про то, что нужно свести все к этим операциям.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
