Комментарии 19
Часто попадаются такие исходники? И что вы делаете, когда оффициальный компилятор/интерпретатор спокойно глотают такие сырцы? Просто если сырец невалиден, то, ИМХО, ни о каком анализе ну может быть и речи.
По поводу runtime C++ в Github есть репозиторий. Вы имели в виду про него? Кстати, буквально 2 дня назад был задан вопрос по поддержке XCode.
Например, для Ruby есть runtime и target для ANTLR 4.4
Теперь она в официальном репозитории =) https://github.com/antlr/grammars-v4/tree/master/ruby
Вообще же парсинг с помощью ANTLR можно начинать не только с корневого узла (обычно compilationUnit), но и вообще с произвольного (например, methodDeclaration). При изменении тела метода можно будет вызывать только метод methodDeclaration для парсинга измененного фрагмента кода (в ANTLR для парсинга файла целиком одним правилом, необходимо добавлять токен EOF в конец. Его отсутствие позволяет парсить код без ошибок не обязательно до конца).
В естественном языке существуют неоднозначно трактуемые фразы (типа «казнить нельзя помиловать»).
Эту фразу часто приводят в качестве примера неоднозначности, но тут неоднозначность из-за того, что фраза грамматические некорректна. Мне больше нравится другой классический пример: «Эти типы стали есть у нас в цеху».
Irony is a development kit for implementing languages on .NET platform. Unlike most existing yacc/lex-style solutions Irony does not employ any scanner or parser code generation from grammar specifications written in a specialized meta-language. In Irony the target language grammar is coded directly in c# using operator overloading to express grammar constructs. Irony's scanner and parser modules use the grammar encoded as c# class to control the parsing process.
Сгенерированный код, конечно, не самый приятный, но и не кромешный ужас: отлаживать можно (хотя я в него практически не смотрю: для анализа пользуюсь другими средствами). Размер кода также зависит от грамматики (грамматику тоже можно оптимизировать). Ну и да — утверждение про лучшую скорость работы (и на сколько лучшую?) хорошо бы подтвердить фактами. Сгенерированный код статический, а значит может неплохо оптимизироваться компилятором.
Но даже без выигрыша по скорости, работа с граматикой не требует выходить из области знаний и инструментария своего стэка.
Все равно нужно иметь представление о грамматиках, токенах, терминалах, AST и т.д.
Под .NET, кстати, есть еще один интересный генератор парсеров LLLPG, но я подробно не изучал его. Авто пишет, что занялся этим проектом после того, как столкнулся с непреодолимым багом в C# рантайме ANTLR 3. В сравнении с ANTLR, автор приводит следующие преимущества:
- минимальный размер рантайма. Сгенерированный код парсера похож на написанный вручную код;
- скорость кода приоритетней понятности. Автор используется конструкции
goto
иswitch
для максимизации производительности.
Однако и ANTLR с 3 версии шагнул далеко вперед. Так что не знаю, насколько актуальны эти пункты.
Теория и практика парсинга исходников с помощью ANTLR и Roslyn