> Хвалятся - авторы lemon его фичами.

где? на всякий случай: перечисление != похвальба.

> Я всегда нежно любил, когда потребитель сам данные требует

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

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

штука в том, что объединить «управляемый» парзер и лексер в одну сущность совсем несложно. а вот «разорвать» лексер и парзер в случае, когда парзер сам всё решает — шибко сложнее.

> может, правда с ними красивее получается.

иногда — красивей. достаточно часто для простых грамматик делать zone allocator лениво, а хранить дополнительную информацию в токене удобно. используем malloc(), при этом не напрягаемся по поводу того, кто и когда позовёт free().

p.s. или мегахаки типа «предпросмотра на токен вперёд и вызова разных парзеров в зависимости от». согласен, это можно и грамматикой сделать. но иногда бывает нужно и вот так — проще получается.