Блог

У меня есть анализатор файлов, который использует permute from parsec для объединения различных Parser файлов. Похоже permute , что это позволяет использовать только Identity монаду, что, я уверен, снижает алгоритмическую сложность.

Теперь я пытаюсь преобразовать весь свой код синтаксического анализа в use MyErrorClass m => ParsecT String () m , где Monad m => MyErrorClass m a class со специальной обработкой ошибок. В частности, код, который использует permute now, должен комбинировать синтаксические анализаторы, которые требуют MyErrorClass m , чтобы они могли предоставлять структурированные ошибки, а не просто использовать fail . ( permute используется только при анализе файлов конфигурации модуля для языка программирования. Формат файла позволяет встраивать некоторые языковые конструкции, повторно используя синтаксические анализаторы из компилятора.)

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

Прежде чем я сделаю что-нибудь серьезное, мне не хватает простого решения parsec ? Может быть, я могу как-то вставить ParsecT String () m в permute from parsers , а не в parsec ? (Это добавило бы зависимость, но, возможно, оно того стоит.)

Редактировать:

Вот некоторые сведения о том, почему структурированные ошибки полезны для синтаксического анализа.

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

Я часто получаю ошибки синтаксического анализа, похожие на expected //, /* or argument type , и это может занять некоторое время (для меня, создателя языка), чтобы понять, какой анализатор вызывается.

MyErrorClass позволяет структурировать сообщения об ошибках, например

 ("In parsing of function declaration for "    show f) ??> do
  -- parse the components of function f
  -- any error messages here will be nested under the message above
 

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

Наконец, использование MyErrorClass также допускает ошибки с быстрым отказом, которые не могут быть подавлены с помощью try или <|> . (В нескольких местах у меня есть явные сообщения об ошибках за использование устаревшего синтаксиса.)

Как предположил @danidiaz, parser-combinators легко решает буквальную проблему перестановки ParsecT .

Предостережение заключается в том, что использование ParsecT с a Monad m , которое преобразует ошибки (даже свои собственные), не особенно полезно, кроме возможности использовать ошибки с быстрым отказом, которые не могут быть проигнорированы <|> and try .

• Вы не можете «понизить» состояние ошибки ParsecT m собственного типа ошибки to, потому что (AFAIK) нет способа получить доступ к текущему состоянию ошибки ParsecT .
• ParsecT не хватает чего-то сопоставимого с StateT ‘s mapStateT . Это означает, что нет способа преобразовать ошибку, сохраненную в m , без фактического выполнения синтаксического анализатора с runPT помощью (и т.д.) , Что невозможно выполнить в середине синтаксического анализа.

Таким образом, ParsecT не происходит утечки m таким же образом, что StateT и делает некоторые m функции недоступными изнутри ParsecT .