Очередной, в какой-то степени. К БНФ и bison оно, тем не менее, отношения почти не имеет. Парсинг всяких текстов (исходников ли, каких-нибудь текстовых форматов разметки), как правило, упирается в то, что один и тот же символ алфавита (буква "a", скажем), может иметь совершенно разную роль в зависимости от контекста - может быть частью литерала, идентификатором, названием тэга, частью ключевого слова и т.д., и этот самый контекст на самом деле весьма нетривиально вычислить. Умные люди для этого придумывают всякие LL-, LR-, LALR- и прочие SLR и т.д. lexx/yacc/bison/т.п. работают как раз в этих парадигмах и львиная доля усилий там тратится именно на то, чтобы понять - вот эта буква "a", что мы только что считали - это вообще что.

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

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

Форматы хранения MyISAM, InnoDB и SQLite, кстати, мы вполне умеем разбирать ;)

На Scala, на самом деле :)

Поддержку C++ мы делаем уже месяц как, но, как выясняется, это несколько сложнее, чем казалось на первый взгляд.

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

Оно с одной стороны и не планируется тьюринг-полное, это по логике своей — DSL, с четко ограниченной областью применения.

ASN.1 можно сравнивать с protobuf или, скажем, как продвинутый вариант bencoded или BSON. Т.е. это все варианты серилизации каких-то структур данных из памяти в поток и обратно, причем сам механизм сериализации фиксированный. KS — это инструментарий для парсинга произвольных потоков. Скажем, PNG-файл или там какие-нибудь пакеты из сетевого трафика.

Тут в какой-то степени двоякая ситуация. С одной стороны — никто не запрещает в императивном уже режиме из языка дергать парсеры как угодно и комбинировать их результаты. Это по сути примерно то же самое, что есть в Preon — и это все можно, но (1) оно будет привязано к одному конкретному языку, (2) это императивно, а не декларативно.

С другой стороны — по идее нужна какая-то более гибкая расширяемость, но оставаясь в декларативных рамках. Очень много что дают value instances (по сути внутри там — некий язык выражений, который гарантированно компилируется в соответствующее выражение на Java/JS/Python/Ruby), но они тоже не панацея, плюс они решают только задачу чтения (бинарник => классы), но не записи (классы => бинарник). Нужно придумывать что-то еще.

> для бигдаты было бы полезно простую интеграцию в виде преобразования в avro,
> например.

Avro — в смысле, с генерируемых классах сразу Avro-аннотации генерировать, как-то так?

> прекрасно те же cdr разбирать. там за такой разбор с
> медиейшеном платят ой как много.

CDR — имеются в виду всякие логи сотовых операторов и прочая биллинг-ориентированная тематика?