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

I>>Это же чистой воды конспироложество. У тебя "написано в книге дракона" это эдакое универсальное объяснение для всего, с чем ты не согласен.
WH>Наоборот. Я говорю, что книга дракона плохая по тому что там написано то с чем я не согласен.

Именно _написано_ _то_, что с чем ты не согласен?
Там явно сказано "мы вам преподнесли лучшие мировые разработки, не думайте никуда больше смотреть"?
Что-то я там такого нигде не видел. Назови номер страницы.

WH>И ещё хуже то что её всем впаривают как образец для подражания.

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

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

N>Это другой вопрос (если это вообще так), слабо связанный с содержанием самой книги. Но ты можешь подтвердить, что именно "впаривают" как образец? Причём "всем"?
N>Ты не раздул муху до слона?
Когда человек спрашивает, как написать компилятор первое что предлагают это книга дракона. И на этом сообщении всегда образуется куча положительных оценок.
Эту книгу даже в фильмах упоминают.

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

N>Для того, чтобы на нём сделать грамматику, нужно полдесятка простых правил. Разумеется, если не пытаться впрячь лебедя, рака и щуку, как сделали в C++.
В С++ с точки зрения парсера ничего сложного нет.
Там сложности с типизацией начинаются.

N>Из названных мной 84 большинство этих грамматик просты, как угол дома. И, при этом, тотально декларативны, что скорее в плюс — хотя бы потому, что TDOP жёстко привязывает код парсинга, а BNF-like декларации с привешенным к ним кодом универсально ложатся под любой генератор парсера.
Это опять не правда.
1)TDOP бывает вполне декларативным. Нитра это прекрасно демонстрирует.
2)Все генераторы персеров имеют разный синтаксис. И что ещё хуже разные алгоритмы разбора. Так что перенести можно только очень простые грамматики. Если грамматика чуть сложнее, то о переносе без серьёзного переписывания не может быть и речи.
Исключение только дженерал парсеры. Но они все как один тормоза.

N>А вот то, что было бы полезно, так это подходы, как не впасть при расширении грамматики в ту же позу, куда попал C++. Но TDOP это тоже не решает, и Nitra не решает.
В чём конкретно проблема?

N>"Во всех институтах" "вдалбывают" одновременно LL и LR. С разным набором специализаций, понятно, но дают оба.
Говно коровье и говно свиное. Пахнут по-разному. Но суть одна.

N>Я знаю про TDOP, хотя никогда не зарабатывал написанием компиляторов. А те, кто всерьёз занялся, способны хотя бы пролистать список методов в википедии. Поэтому все, кому надо, давно про него знают. И если не используют, то причина не в LALR.
И откуда ты про него узнал?

N>OK, можно сократить тему только до TDOP. Но в таком случае она сильно пострадает. Насколько я успел увидеть в нитре, у тебя таки описательный подход, а TDOP требует руками выписывать код всех nud/led/etc.
Ничего он не требует.
Вот простенький гибрид PEG'а и TDOP'а.
http://rsdn.org/forum/dotnet/6700752.1

Автор: WolfHound
Дата: 16.02.17

    static void Main(string[] args)
    {
      var expr = new ChoiceParser();
      expr.Add(new IntParser());
      expr.Add("x");
      expr.Add("(", expr, ")");
      expr.Add("+", expr.Get(1000));
      expr.Add("-", expr.Get(1000));
      expr.Add(expr.Get(10), "+", expr.Get(10));
      expr.Add(expr.Get(10), "-", expr.Get(10));
      expr.Add(expr.Get(20), "*", expr.Get(20));
      expr.Add(expr.Get(20), "/", expr.Get(20));
      foreach (string s in new string[] { "*x", "+x", "x", "x+-x", "x-+x", "x+x", "x*123-123/x", "x*(123-123)/x", "x*123-x12", "x*x-(x+x)", "x*x+(x+)", "x*x/(x+12)"})
      {
        var pos = expr.Parse(0, s);
        Console.WriteLine("{0}, {1}, {2}", s, pos, pos == s.Length);
        Console.WriteLine();
      }
    }

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

N>>Это другой вопрос (если это вообще так), слабо связанный с содержанием самой книги. Но ты можешь подтвердить, что именно "впаривают" как образец? Причём "всем"?
N>>Ты не раздул муху до слона?
WH>Когда человек спрашивает, как написать компилятор первое что предлагают это книга дракона.

Ну и? В качестве общего обзора она вполне неплохо идёт. Хотя и альтернатив полно.

WH> И на этом сообщении всегда образуется куча положительных оценок.
WH>Эту книгу даже в фильмах упоминают.

То есть твоя претензия именно в том, что у неё самоподдерживающаяся репутация за счёт того, что когда-то вышла в топ?
Или таки в том, что читающие решают, что в ней, как в Коране, есть всё?

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

N>>Для того, чтобы на нём сделать грамматику, нужно полдесятка простых правил. Разумеется, если не пытаться впрячь лебедя, рака и щуку, как сделали в C++.
WH>В С++ с точки зрения парсера ничего сложного нет.
WH>Там сложности с типизацией начинаются.

Когда нельзя понять, нечто есть объявление функции или переменной, пока не разберёшь до конца и не прочитаешь контекст (часть из которого задаётся уже после этой спорной строки) — это не "сложности с типизацией", это именно парсинг.

N>>Из названных мной 84 большинство этих грамматик просты, как угол дома. И, при этом, тотально декларативны, что скорее в плюс — хотя бы потому, что TDOP жёстко привязывает код парсинга, а BNF-like декларации с привешенным к ним кодом универсально ложатся под любой генератор парсера.
WH>Это опять не правда.
WH>1)TDOP бывает вполне декларативным. Нитра это прекрасно демонстрирует.

OK, соглашусь. Я знаю реализации TDOP по тексту грамматики или по набиванию правил универсального типа (вроде такого), но не привязал их к оригинальному методу Пратта, потому что многие считают, что TDOP == Pratt и вариантов быть не может. Сойдёмся на том, что это расширение Пратта.

WH>2)Все генераторы персеров имеют разный синтаксис.

Почти все они из наиболее популярных классов — это разные кодирования абстрактного BNF и примешанные к ним управляемые правила языка реализации. Перенос с одного на другой делается заменой типа ":" на "=" и тому подобное.
Если ты про возможность, например, собрать в одном правиле несколько вариантов с приоритетами между ними, то они исключаются из подобных возможностей — берётся некий общий базовый набор возможностей.

WH> И что ещё хуже разные алгоритмы разбора. Так что перенести можно только очень простые грамматики. Если грамматика чуть сложнее, то о переносе без серьёзного переписывания не может быть и речи.
WH>Исключение только дженерал парсеры. Но они все как один тормоза.

Кто у тебя эти general? Пару имён хотя бы.

N>>А вот то, что было бы полезно, так это подходы, как не впасть при расширении грамматики в ту же позу, куда попал C++. Но TDOP это тоже не решает, и Nitra не решает.
WH>В чём конкретно проблема?

В том, как предсказать удобную расширяемость грамматики без конфликтов интерпретации.
Во времена Фортрана не могли подумать о том, чем обернётся их "integer zz".

N>>Я знаю про TDOP, хотя никогда не зарабатывал написанием компиляторов. А те, кто всерьёз занялся, способны хотя бы пролистать список методов в википедии. Поэтому все, кому надо, давно про него знают. И если не используют, то причина не в LALR.
WH>И откуда ты про него узнал?

Просто пошёл читать see also на страничках.
Это доступно любому студенту. Только раньше для этого надо было выходить из дома.

N>>OK, можно сократить тему только до TDOP. Но в таком случае она сильно пострадает. Насколько я успел увидеть в нитре, у тебя таки описательный подход, а TDOP требует руками выписывать код всех nud/led/etc.
WH>Ничего он не требует.

См. выше.

WH>Вот простенький гибрид PEG'а и TDOP'а.

Забавно. Стиль кодирования мне не нравится, но идея понятна.

В любом случае к исходному вопросу про книгу это отношения не имеет, ну кроме уже давно сказанного — добавить в книгу три страницы на TDOP не ухудшило бы, но и не улучшило. Так как добавить можно было бы на уровне "по три страницы" по каждому пункту, книга могла бы запросто увеличиться в пару раз в толщине. Они и так резали по живому, мне кажется.

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

N>Когда нельзя понять, нечто есть объявление функции или переменной, пока не разберёшь до конца и не прочитаешь контекст (часть из которого задаётся уже после этой спорной строки) — это не "сложности с типизацией", это именно парсинг.
И чего тут сложного? Нитра такое парсит без проблем. Просто создаёт неоднозначность и всё.
А дальше типизатор разберётся.
Хотя для LALR'а это конечно большая проблема.

N>Если ты про возможность, например, собрать в одном правиле несколько вариантов с приоритетами между ними, то они исключаются из подобных возможностей — берётся некий общий базовый набор возможностей.
Минимум возможностей между LL(1) и LALR это такой убогий песец что вообще ни в какие ворота.
Короче перенос больших грамматик без серьёзного переписывания — это тупо миф.

N>Кто у тебя эти general? Пару имён хотя бы.
GLR, GLL, Earley parser и ещё несколько так сразу имена не вспомню.

N>В том, как предсказать удобную расширяемость грамматики без конфликтов интерпретации.
1)Парсим неоднозначности потом разбираемся типизатором. В перегрузке синтаксиса по типам ничего сложного нет. От перегрузки функций ничем не отличается.
2)Нитра подразумевает создание языков где синтаксис является библиотекой. Те пользователь может выкинуть устаревший синтаксис так же как сейчас выкидывает устаревшие библиотеки.
Более того синтаксис можно включать и выключать внутри одного файла.

N>Во времена Фортрана не могли подумать о том, чем обернётся их "integer zz".
Я не знаю, что там в фортране происходит.

N>Забавно. Стиль кодирования мне не нравится, но идея понятна.
Это было написано за пол часа по приколу.

N>В любом случае к исходному вопросу про книгу это отношения не имеет, ну кроме уже давно сказанного — добавить в книгу три страницы на TDOP не ухудшило бы, но и не улучшило. Так как добавить можно было бы на уровне "по три страницы" по каждому пункту, книга могла бы запросто увеличиться в пару раз в толщине. Они и так резали по живому, мне кажется.
Половину книги, посвящённую парсерам можно было тупо выбросить и заменить вот на эти 3 страницы. Один чёрт TDOP лучше чем то что там описано.

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

N>>Когда нельзя понять, нечто есть объявление функции или переменной, пока не разберёшь до конца и не прочитаешь контекст (часть из которого задаётся уже после этой спорной строки) — это не "сложности с типизацией", это именно парсинг.
WH>И чего тут сложного? Нитра такое парсит без проблем. Просто создаёт неоднозначность и всё.
WH>А дальше типизатор разберётся.

Ну я, конечно, понимаю подход "после парсера — хоть потоп, потому что не наше дело", но там (вокруг типизатора), собственно, и находится основная сложность и более того, утверждают, что там парсер и типизатор это сопрограммы, а парсеру приходится пересчитывать логику некоторых участков. Я не удивлён.

N>>Кто у тебя эти general? Пару имён хотя бы.
WH>GLR, GLL, Earley parser и ещё несколько так сразу имена не вспомню.

Ну вот потому я и говорю, что современный подход — продумывать заранее, как не впадать в позу, что когда-то придётся переходить на "general тормоза" или ручные самописки.

N>>В том, как предсказать удобную расширяемость грамматики без конфликтов интерпретации.
WH>1)Парсим неоднозначности потом разбираемся типизатором. В перегрузке синтаксиса по типам ничего сложного нет. От перегрузки функций ничем не отличается.
WH>2)Нитра подразумевает создание языков где синтаксис является библиотекой. Те пользователь может выкинуть устаревший синтаксис так же как сейчас выкидывает устаревшие библиотеки.

Не-а, устаревший выкидывать нельзя. Вот такая задача в 99% реальных случаев.

N>>Во времена Фортрана не могли подумать о том, чем обернётся их "integer zz".
WH>Я не знаю, что там в фортране происходит.

Так не в Фортране, а после него. В C со всеми клонами.
Описание в духе "int zz;", а позднее "int f(int, double);" приводит к монстрам типа "typedef typeof(typeof(int(*)(int)) (*)(int)) fn2;" (в лучшем случае, если оно вообще компилируется).
А вот паскалеобразное "type fp = function(int, function (double):double):int" таких проблем не имеет.
Вот обсуждение рядом

Автор: netch80
Дата: 09.01.18

это хорошо показывает.

Так как, будут хоть какие-то идеи, как предположить подобные грабли при развитии грамматики и избежать их? Я не ёрничаю ничуть, это тема, которая никак, насколько вижу, не покрывается ни теорией, ни отделённой практикой.
PEGʼи всякие не вспоминать, форсированные приоритеты это не лечение, а купирование симптомов.

N>>Забавно. Стиль кодирования мне не нравится, но идея понятна.
WH>Это было написано за пол часа по приколу.

OK, ясно.

N>>В любом случае к исходному вопросу про книгу это отношения не имеет, ну кроме уже давно сказанного — добавить в книгу три страницы на TDOP не ухудшило бы, но и не улучшило. Так как добавить можно было бы на уровне "по три страницы" по каждому пункту, книга могла бы запросто увеличиться в пару раз в толщине. Они и так резали по живому, мне кажется.
WH>Половину книги, посвящённую парсерам можно было тупо выбросить и заменить вот на эти 3 страницы. Один чёрт TDOP лучше чем то что там описано.

В этом есть смысл. Но тогда и книгу надо делать чуть иначе. По типу "практическое руководство по..." с "лёгкими" механизмами и примерами реализаций на стандартных тулах. А в ссылках сослаться и на дракона.

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

N>Ну я, конечно, понимаю подход "после парсера — хоть потоп, потому что не наше дело", но там (вокруг типизатора), собственно, и находится основная сложность и более того, утверждают, что там парсер и типизатор это сопрограммы, а парсеру приходится пересчитывать логику некоторых участков. Я не удивлён.
Если парсер может строить лес деревьев, то не нужно переплетать логику парсера и типизатора.
Соответственно даже с учётом того что типизатору нужно будет работать с неоднозначным АСТ он будет проще чем в случае с переплетённой логикой.
И основные сложности в типизаторе С++ связаны не с неоднозначностями, а с тем что система типов в С++ дурная.
Причём её полнота по Тьюрингу не является главной проблемой. Для того чтобы с этим справиться типизатор нужно сразу начинать писать, как интерпретатор чистого функционального языка с динамической типизацией.

N>Ну вот потому я и говорю, что современный подход — продумывать заранее, как не впадать в позу, что когда-то придётся переходить на "general тормоза" или ручные самописки.
Удачи тебе придумать как это сделать на подмножестве LL(1) и LALR.

N>Не-а, устаревший выкидывать нельзя. Вот такая задача в 99% реальных случаев.
Это догма языков с монолитным синтаксисом.
В этом случае мы добавляем синтаксис сразу всем. Даже тем, кому он не нужен.
И забираем его у всех. Даже тех кому он нужен.
В случае с модульным синтаксисом мы можем добавить синтаксис даже если он нужен одному проценту пользователей. Остальные его просто не подключат, и он не будет их трогать.
Или удалить синтаксис из поставки по умолчанию. А те пол процента пользователей, которые его всё ещё используют смогут вернуть его обратно одной строкой в конфигурации проекта.

N>Так не в Фортране, а после него. В C со всеми клонами.
N>Описание в духе "int zz;", а позднее "int f(int, double);" приводит к монстрам типа "typedef typeof(typeof(int(*)(int)) (*)(int)) fn2;" (в лучшем случае, если оно вообще компилируется).
N>А вот паскалеобразное "type fp = function(int, function (double):double):int" таких проблем не имеет.
N>Вот обсуждение рядом

Автор: netch80
Дата: 09.01.18

это хорошо показывает.
Если у нас язык на базе нитры то:
1)Добавляем новый синтаксис типов.
Нитра без проблем может разобрать оба варианта одновременно.
2)Пишем код для автоматического переписывания старого синтаксиса в новый.
Опять же на базе нитры это сделать просто.
3)Конвертируем старый синтаксис в новый.
4)Отключаем старый синтаксис.

Этот процесс может происходить в течении нескольких лет в разных проектах с разной скоростью.
В конце концов останутся доли процента ретроградов, которые отказываются переходить на новый синтаксис. Ну и фиг с ними. На интеграцию модулей между собой синтаксис вообще никак не влияет.

N>Так как, будут хоть какие-то идеи, как предположить подобные грабли при развитии грамматики и избежать их? Я не ёрничаю ничуть, это тема, которая никак, насколько вижу, не покрывается ни теорией, ни отделённой практикой.
Только опыт разработчика языка.
Но если ошибка была допущена, то в случае с языками с модульным синтаксисом её можно исправить.