Comments 22
А вот какой парсер проще получается, декларативный на функциональном ЯП или императивный на обычном ЯП?
Обычный человек боится использовать лексеры и парсеры, а вместо них пишет велосипед на регулярных выражения.
На самом деле обычный человек очень правильно делает, что избегает сложно понимаемые LR парсеры, lex, yacc и подобные пережитки прошлого. Гораздо проще, легче и важнее начинать с самописных recursive descent парсеров. Потом может посмотреть на PEG, которые такие парсеры генерируют.
К теории по компиляторам вообще стоет очень скептически относиться, слишком много там наследия прошлого.
> это то, что автор статьи называет «велосипедом»
Кажется, теперь парсером можно называть только результат обработки инструкций для yacc и пр.
Кажется, теперь парсером можно называть только результат обработки инструкций для yacc и пр.
Почему?
Есть представление об ИТ как практическом применении накопленных другими знаний, то есть, любые знания от других людей, если они известны, считаются проверенными и применимыми. Дальше эта идея развивается до уровня «кто не переиспользует, тот велосипедостроитель», то есть позитивная концепция переиспользования используется для обоснования негативного отношения к не-переиспользующим. При этом предполагается, что 95% айтишников серая масса и в принципе не имеет достаточных знаний для того, чтобы делать что-то иначе, чем большинство.
Дальше на догму об единственности известного уже навешивают интересы разных интересантов, что закрепляет догму.
Иногда целые страны (см. РФ) руководствуясь принципом «don't repeat yourself» устраняются от занятия в предметных областях, которые уже кем-то освоены.
То есть, отвечая на ваш вопрос, для компиляторов уже 10 лет есть yacc, а кто использует что-то другое, или, не дай бог, пишет от руки, тот лох и вон из профессии.
Дальше на догму об единственности известного уже навешивают интересы разных интересантов, что закрепляет догму.
Иногда целые страны (см. РФ) руководствуясь принципом «don't repeat yourself» устраняются от занятия в предметных областях, которые уже кем-то освоены.
То есть, отвечая на ваш вопрос, для компиляторов уже 10 лет есть yacc, а кто использует что-то другое, или, не дай бог, пишет от руки, тот лох и вон из профессии.
Я просмотрел статью. И если сравнивать с ANTLR, то в последем используются более чистый формат для описания грамматик, без лишнего мусора в фигурных скобочках. А вы сравнивали?
Спасибо за статью. Некоторое время назад я находил небольшой гайд о том, как проделать похожие шаги на чистом Erl, но на английском. Понимания того, что делается, практически не было. Тут же все на много понятнее. Пишите еще!
Ргулярки весьма ограничены в грамматиках, которые вы пытаетесь ими описать (к примеру попробуйте парсить html регулярками) (переводчик: на самом деле — нет. Но на ассемблере тоже можно написать кластерное приложение. Масштаб проблемы приблизительно одинаковый)
Почему не получится распарсить HTML регулярками
Лично я люблю комбинаторные монадические парсеры. По моему с этой техникой генераторы парсеров становятся не слишком нужны — единственное их преимущество это возможность оптимизации.
Кстати, на Erlang была для этого библиотека.
Кстати, на Erlang была для этого библиотека.
Замените термин "тупиковые" на "терминальные"
Sign up to leave a comment.
Elixir: Готовим парсинг правильно — yecc и leex