re2c 3.0

Вы бы хоть намекнули, что это за зверь такой - лексер…

Если написать «лексический анализатор», станет понятнее?

Какие преимущества данного решения перед нативными для раста? Если в случае Си всё очевидно, то раст намного более приспособлен для кодирования лексера прямо в нём.

Ждём кодогенерации в javascript, очень нужно

вы хоть раз сами то писали лексер? Наблюдается какое-то катастрофическое отсутствие понимания проблематики в этой области

Спасибо за релиз!

С нетерпением ждём ебилдов (и, пользуясь случаем, передаём привет Серёже =)).

По поводу ебилдов, вот https://trofi.github.io/posts/226-farewell-gentoo-dev.html и вот https://trofi.github.io/posts/229-a-month-on-nixos.html, теперь жизнь в NixOS: https://github.com/NixOS/nixpkgs/pull/156972. :)

Вот человек хорошо написал: https://old.reddit.com/r/rust/comments/se4khc/re2c_lexical_analyzer_generator_now_supports_rust/.

Как минимум преимущество в том, что это солидный проект, в котором уже всё давно реализовано и протестировано кучей других солидных проектов. А кодогенерация - штука относительно простая. Т.е. ты берёшь этот re2c и уверен, что через 10 лет у него будут выходит новые версии. А когда ты берёшь какую-то мелкую библиотеку, которую написал какой-нибудь школотрон в качестве своей дипломной работы, ты можешь быть уверен, что он её забросит как только устроится на копирование байтов из жсона в протобуф.

Пусть попросит доступ к gcc сfarm - они хорошие люди, и у них много интересных машин. Не могу на блоге откаментить, там регистрация нужна. Привет!

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

Полезная вещь. И где кстати инфу про Ninja и PHP узнали? Или просто в исходниках подглядели? Ссылочка бы пригодилась.

P. S. Что-то сразу не нашёл. Всё было в конце PDF.

А зачем нужны лексические анализаторы?

Он отличается от более известного аналога flex гибким интерфейсом

А в чём заключается гибкость интерфейса?

Они сильно упрощают жизнь с парсингом и анализом синтаксиса несложных языков (в основном сценарных), на подобии Make, Ninja, HTML... Но скажем для такого языка как C++, такие штуки не годятся от слова совсем.

Но скажем для такого языка как C++, такие штуки не годятся от слова совсем.

Тем не менее, SQL в том же SQLite парсится их lemon'ом вполне на ура.

А зачем их отдельно анализировать? Make сам говорит, что в файле ошибки.

Например для интеграции в продвинутый редактор с подсветкой синтаксиса и подсказками, или в IDE с отладчиками.

А вы с trofi родственники или однофамильцы?

Возможно там не столь сложный синтаксис, я с SQL не работал, ничего про него сказать не могу. Но вот GCC-шники когда пытались Си парсить через bison и flex, не осилил. Слишком сложно и работает медленно. Для такого языка проще самописный анализатор написать, что собственно они и сделали.

Спасибо

С разморозкой меня. Жаль, сообщество gentoo утратило ещё одного адекватного мэйнтейнера.

Ну что же, огромная благодарность ему за всё сделанное и удачи с NixOS. =)

Сгенерированный код интерфейсится с основной программой через несколько базовых операций, которые определяет сам программист. При этом они могут быть определены как макросы, функции, замыкания, переменные и вообще что угодно, лишь бы в конечном счёте получился синтаксически связный код. Например, есть базовая операция YYPEEK (прочитать следующий символ из входных данных) и зависимости от того, как её определить, это может быть от простого разыменования указателя до какого-нибудь чтения из файла, дебага и т.д.

Ещё re2с не подразумевает конкретной формы входных данных: это может быть нуль-терминированная строка, буфер, файл, возможно даже несколько отдельных буферов. Можно делать совсем легковесные лексеры, которые ничего не копируют и не тратят времени на проверки выхода за границу, а можно обрабатывать большие данные (тут подробнее) или данные, которые поступают частями (например через сокет).

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

У гибкости есть обратная сторона — программисту надо немного разбираться в том, что такое лексер и как он работает, чтобы максимально эффективно определить базовые операции. Не все это любят. Но стандартные примеры помогают.

Мы одна большая семья. :)

Ну, к примеру… как бы вы реализовали утилиту file? :)

Мне лично re2c пригодился для анализа малварных сэмплов, а потом для лексера в эмуляторе JS. Кто-то парсит HTTP заголовки, кто-то JSON разбирает, из сокета люди пакеты читают и парсят. Лексический анализ языков программирования — это стандартное. Какой-нибудь парсер логов. В общем, подойдёт везде, где структура данных описывается регулярной грамматикой.

(и, пользуясь случаем, передаём привет Серёже =)).

Его вообще-то Алеша зовут

Владимир

это солидный проект, в котором уже всё давно реализовано и протестировано кучей других солидных проектов

Звучит солидно

Наблюдается какое-то катастрофическое отсутствие понимания проблематики в этой области

Я вот не понимаю, зачем нужен лексер. И как его применять. Объясни, пожалуйста :-)

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

Это просто умное слово для синтаксического парсера. Соответственно нужен если ты хочешь распарсить входные данные с каким-то известным синтаксисом на синтаксические единицы.

Т.е. ты берёшь этот re2c и уверен, что через 10 лет у него будут выходит новые версии

То есть за 10 лет они так и не осилят довести примитивную задачу парсинга до логического завершения, ясно.

Нет такого понятия, как логически завершенная программа. Есть мёртвый проект или живой проект.

Это у вечных беток такие понятия.

Почему я должен быть более уверен в этом проекте, чем к примеру в школотронском растовом nom?

Спасибо! :)

а, так это на нем столько дыр в пых-пых реализовано? зачет

Это просто пиздец, господа!..

Большое спасибо вам за релиз. Часто использую в работе. Если бы можно было бы сделать генерный фронт-энд (типа что бы сам мог генерировать лексер для языков которые не поддерживаются - например для Java) вообще было бы шикарно

Нет такого понятия, как логически завершенная программа. Есть мёртвый проект или живой проект.

Такие программы как tex, qmail, kill, pwgen, cat, cut, hexedit мёртвые или живые?

Спасибо. Можно подробнее про фронтенд? Как я понимаю, идея в том, чтобы программист мог выбирать одну из предопределённых моделей генерации кода (вроде goto с метками или switch в цикле) и настраивать всякие мелочи типа ключевых слов, наличия точек с запятой или скобок в if. Мысль интересная, только надо продумать, что абстрагировать, чтобы побольше языкоа вписалось в эти рамки.

А для конкретно для Java, наверное, совсем немного надо (теперь, когда есть опция --loop-switch и от языка не требуется наличие goto). Можно и полноценный бэкенд запилить.

tex

Stable release 3.141592653 / February 2021; 11 months ago

Живо.

qmail

Оригинальная программа сдохла, есть два живых форка.

kill, cat, cut

GNU Core Utilities, Stable release 9.0 24 September 2021; 4 months ago

Живое, если речь о core utils.

hexedit

Не слышал про такую программу.

pwgen

https://github.com/tytso/pwgen 1459a31 on Sep 3, 2019

Немного шевелится.

Я так понимаю, у вас в re2c есть некая структура данных, по которой и строиться лексер. То есть, можно рассматривать сгенерированный код просто как разные формы сериализации этой структуры данных (например для C одна форма, для GO другая). Было бы интересно иметь API для доступа к этой внутренней структуре данных и тогда можно будет самому писать сериализацию. Хочешь в Java, хочешь в Python, а хочешь в какую-то виртуальную машину

Да, в языках программирования уязвимости вызваны лексером.

Да, в языках программирования уязвимости вызваны лексером.

ИМХО основная проблема - отсутствие верификации исходных данных.
Иногда она конечно есть, а большей частью, нет.
Поэтому exploits были и будут …

Владимир

само-собой, имелся ввиду интерпретатор пых-пых.

Хм, это посложнее. Структура есть, но она сама зависит от языка (например, есть оптимизации, специфичные для конкретного языка, влияющие на форму этой структуры). То есть бОльшая часть трансформаций не зависит от языка, но после того как язык определился, ещё есть много работы перед сериализацией в код. Идея хорошая, но надо думать.

Спасибо! И еще раз спасибо за замечательный продукт!