Изучение комбинаторных парсеров с Rust

[PsyHaSTe]

Монументальная статья! Спасибо, как раз недавно общался насчет парсеров в других языках. Вы не проводили какого-нибудь сравнения самостоятельно? (да, я вижу, что это перевод).

[xGromMx]

Де-факто сейчас мегапарсек в моде, ну и сравнительный обзор
github.com/mrkkrp/megaparsec#comparison-with-other-solutions

[Mingun]

Я было начал сообщать о кривых конструкциях в переводе, но быстро понял, что так придется переписать всю статью. Так что лучше ее все же написать заново — читается ну очень тяжело. Есть и полностью неверный перевод ("Наконец, атрибуты разбора" — серьезно?).

По делу — то, что здесь описано, называется PEG и такие парсеры писать руками на самом языке комбинированием функций — самоубийство. Как обучающая статья очень хорошо (только перевести нормально), но для дела лучше возьмите rust-peg (кстати, корни явно растут из pegjs).

[sashagil]

Что вы посоветуете первым посмотреть, если выбор между nom и rust-peg?

[Mingun]

Я только с pegjs работал, когда заинтересовался Rust-ом, решил посмотреть, есть ли там что-то подобное и стоит ли попробовать написать цель генерации на Rust для pegjs. А там оказывается уже есть точь-в-точь такая же библиотека, причем по некоторому коду у меня сильные подозрения, что это порт pegjs, хотя нигде я этой информации в ее readme не видел.

Посмотрел nom — если важна понятность парсера, то однозначно лучше использовать rust-peg. Как я говорил выше, ручное комбинирование функций никогда не будет таким понятным, как специализированный DSL. А благодаря макросам Rust он очень органично вплетается в процесс сборки приложения. Но если важны какие-то другие критерии, то тут только сравнить или поискать обзоры.

Если для обучения — то однозначно лучше rust-peg.

[zolkko]

Тогда уж pest. Он значительно популярнее.

[ababo]

Мда, красиво, конечно, и сложно. А потом подумалось, насколько же проще написать ad-hoc парсер. И поддерживать его, наверное, будет куда легче.

[freecoder_xx]

Clone пришлось затащить в Parser и добавить как доп. зависимость для типов F — тогда one_or_more через zero_or_more сработал.

[akaAzazello]

>>Представляю вашему вниманию перевод статьи «Learning Parser Combinators With Rust».
сорри за off-topic — как же всё-таки приятно видеть информацию о том, что это перевод, и ссылку на оригинал в первой строчке статьи.

[vitvakatu]

Статья из песочницы — а там ставить "перевод" нельзя по какой-то странной причине.

[akaAzazello]

Но ведь в таком случае информация о переводе будет в конце статьи, а не в шапке.

И когда статью переводят переводчики, а не профильные специалисты — после нескольких абзацев бывает очень грустно читать, и до ссылки на оригинал, где всё правильно — уже можно и недолистать;)

[Cerberuser]

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

[n0dwis]

Спасибо, хорошая статья. Как раз на неделе пришлось столкнуться с чем-то подобным. Реализовал на конечных автоматах, теперь думаю переписать — этот подход более понятный.
Единственное — а почему всё в функциональном стиле? Возможно, это было бы оправдано для универсальной библиотеки для парсинга, но в обучающих целях, на конкретном языке — императивный стиль был бы проще.

[YuryZakharov]

В императивном стиле композиция несколько болезненна.

[n0dwis]

Объясните?