Какая технология разбора Haskell наиболее приятна в использовании и почему?

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

Позвольте сформулировать для целей этого вопроса, что, если производительность технологии является патологически плохой, производительность здесь не самая большая проблема.

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

Пожалуйста, дайте мне представление о размере и сложности грамматик, с которыми вы работали, когда отвечаете на этот вопрос. Кроме того, использовали ли вы какие-либо заметные "расширенные" особенности рассматриваемой технологии и каковы были ваши впечатления от них.

Конечно, ответ на этот вопрос может зависеть от домена, и в этом случае я был бы рад узнать этот факт.

Ответ 1

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

Если у вас есть грамматика LR (например, вы работаете из грамматики Yacc), то это хорошая работа, чтобы превратить ее в LL, подходящую для Parsec или uu-parsinglib. Однако многие, sepBy и т.д. Парнеры очень полезны здесь, но вы должны ожидать, что парсер будет медленнее, чем Happy + Alex.

Для парсинга комбинаторов LL uu-parsinglib и его предшественника uu-parsing хороши, но им не хватает чего-то вроде Parsec Token и языковых модулей, поэтому, возможно, менее удобно. Некоторые люди, такие как Малькольм Уоллес Парселиб, потому что у них есть другая модель для Parsec для возврата, но у меня нет опыта с ними.

Если вы декодируете какой-то форматированный файл, а не что-то вроде языка программирования, Attoparsec или подобное может быть лучше, чем Parsec или uu-parsinglib. Лучше в этом контексте быть быстрее - не только ByteString vs. Char, но я думаю, что Attoparsec делает меньше работы в отношении обработки ошибок/отслеживания местоположения источника, поэтому парсерам следует работать быстрее, поскольку они выполняют меньше работы на элемент ввода.

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

Для анализа LR я нашел, что Ralf Hinze Frown был лучше, чем Happy - лучшая поддержка ошибок и более удобный формат для файлов грамматики, но Frown не активно поддерживается и не находится в Hackage. Я думаю, что это LR (k), а LR (1), что означает, что он более мощный w.r.t. смотреть вперед.

Производительность на самом деле не является большой проблемой w.r.t. грамматика. Языки программирования имеют сложные грамматики, но вы можете ожидать довольно мелкие файлы. Что касается форматов файлов данных, то разработчику этого формата действительно нужно проектировать его таким образом, чтобы он мог эффективно анализировать. Для комбинаторных парсеров вам не нужно много дополнительных функций для файла формата данных - если вы это сделаете, либо формат плохо разработан (это иногда случается, к сожалению), либо ваш парсер.

Для записи я написал парсер C с Frown, GL-shading language с Happy, незавершенным C-парсером с UU_Parsing и многими вещами с Parsec. Выбор для меня был тем, с чего я начинаю, грамматика LR - Frown или Happy (теперь Happy as Frown не поддерживается), в противном случае обычно Parsec (как я уже сказал, uu_parse хорош, но не имеет удобства LanguageDef). Для двоичных форматов я откатываюсь, но у меня обычно есть особые требования.

Ответ 2

У нас был большой успех с использованием "uu-parsinglib" - мы переключились на это с Parsec, поскольку он довольно гибкий и мощный - например, он может поддерживать ленивый синтаксический анализ, если это необходимо, и вам не нужно явно используйте комбинатор (например, "попробуйте" в Parsec), чтобы отметить возможные точки отслеживания обратной связи.

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

Ответ 3

В последнее время я переписываю парсер DSL в uu-parsinglib, который был написан в parsec. Я обнаружил, что это значительно упростило программу. Моя главная мотивация заключалась в том, чтобы получить автокорректирующий аспект. Это просто работает. Это практически бесплатно! Кроме того, я предпочитал писать свой парсер в аппликативном стиле, а не в монадическом стиле Parsec.