AT
Во внешнюю зависимость я включаю и библиотеку поддержки(существенную по размерам), которая может идти в комплекте с генератором и которой не будет при ручном создании
Так а какой генератор использует такую библиотеку? Bison? 🙂
Size: a a a
2020 March 15
К
Обратите внимание, что важно выполненин двух условий, а не одного
AT
Ну мой опыт написания рукописных парсеров, говорит о том, что рекурсивный спуск работает быстро и точно быстрей, чем делается многими распространёнными генераторами парсеров
Эмм... Можно считать, что он работает достаточно быстро, но вот потребление памяти (стека) - не айс. Особенно в патологических случаях. Ну и в самом паталогическом случае прямой левой рекурсии - просто зацикливается.
AT
Так я всё равно не знаю ни одного генератора парсеров, генерирующего "человекочитаемый" код. Да и не интересуюсь по вышеозвученным причинам. 🙂
К
так а зачем мне левая рекурсия? Вы ввели третье условие - парсить всё что угодно?
К
Так я всё равно не знаю ни одного генератора парсеров, генерирующего "человекочитаемый" код. Да и не интересуюсь по вышеозвученным причинам. 🙂
Зачем тогда отвечали? Достаточно было этого сообщения
AT
так а зачем мне левая рекурсия? Вы ввели третье условие - парсить всё что угодно?
А с регулярными языками вообще всё понятно - для них и генерация-то не нужна. Поэтому генераторы парсеров рассчитаны на более-менее произвольные контекстно-свободные языки. Отсюда и вопрос левой рекурсии. 🤷♀️
AT
Зачем тогда отвечали? Достаточно было этого сообщения
Захотелось. 🙂
К
А с регулярными языками вообще всё понятно - для них и генерация-то не нужна. Поэтому генераторы парсеров рассчитаны на более-менее произвольные контекстно-свободные языки. Отсюда и вопрос левой рекурсии. 🤷♀️
Ну почему не нужно? Как быстрый старт для любителей рекурсивного спуска
А
Интереса ради. Существуют ли такие генераторы парсеров, которые бы на выходе давали код, схожий с рукописным без внешних зависимостей?
antlr генерировал вполне понятный код, но я им очень давно пользовался. вообще, я думаю LL(k) разбор вполнн человеко-читабельный в отличие от LR, который у lex, там автомат который фиг поймешь почему именно такой сгенерился :)
TT
любые фичи где-то да уже есть, это не повод не развивать язык, который по многим топам занимает топ1-2 самых используемых языков 😊
кто пишет на js — говорит что топ1 js
кто пишет на сишечке-с-плюсами — говорит что сишечка-плюсы топ1
кто пишет на java — говорит что джавка топ1
ор :)
извините, оффтоп, но ведь ор!)
кто пишет на сишечке-с-плюсами — говорит что сишечка-плюсы топ1
кто пишет на java — говорит что джавка топ1
ор :)
извините, оффтоп, но ведь ор!)
E
малр того что оффтоп так еще и ответ на старое сообщение
TT
да не, не, какое же оно старое — даже не протухло 🙈😂
DP
Интереса ради. Существуют ли такие генераторы парсеров, которые бы на выходе давали код, схожий с рукописным без внешних зависимостей?
Ragel хорошо идет с флагом -G2, выплевывает чистый сишный код, по которому можно вменяемо в отладчике на микроконтроллере шастать, состояния и переходы помечены метками
DP
Насчёт внешних зависимостей вообще не понятно - я не припоминаю генератора парсеров, который бы использовал внешние зависимости.
Насчёт человекочитаемости - сделать-то более-менее можно, просто у генераторов парсеров в приоритете скорость разбора и потребление памяти, а это противоречит человекочитаемости. Ну и вообще, не очень понятно зачем кому-то сильно вчитываться в сгенерированный код?..
Насчёт человекочитаемости - сделать-то более-менее можно, просто у генераторов парсеров в приоритете скорость разбора и потребление памяти, а это противоречит человекочитаемости. Ну и вообще, не очень понятно зачем кому-то сильно вчитываться в сгенерированный код?..
libc, буферизация ввода через файловый io
DP
кто пишет на js — говорит что топ1 js
кто пишет на сишечке-с-плюсами — говорит что сишечка-плюсы топ1
кто пишет на java — говорит что джавка топ1
ор :)
извините, оффтоп, но ведь ор!)
кто пишет на сишечке-с-плюсами — говорит что сишечка-плюсы топ1
кто пишет на java — говорит что джавка топ1
ор :)
извините, оффтоп, но ведь ор!)
мне эту проблему чаще формулировали в виде теоремы Эскобара, и наоборот пишут на том что вызывает минимальный разрыв мозга
IK
Ну мой опыт написания рукописных парсеров, говорит о том, что рекурсивный спуск работает быстро и точно быстрей, чем делается многими распространёнными генераторами парсеров
Если грамматика простая, без неоднозначностей, то на выходе и будет плюс-минус рекурсивный спуск.
IK
Если в ANTLR не происходит переключения в полный LL режим (по дефолту SLL) , то парсинг всегда будет быстрым.
IK
Почему? Есть какое-то принципильное препятствие в генерации, к примеру, парсера по методу рекурсивного спуска?
Есть, свобода в описании грамматики. Чем меньше задумываешься о ней, тем сложнее генерируемый код. В рукописном нельзя левую рекурсию и неоднозначности.
К
Спасибо. На то, чтобы генерировался читаемый код для грамматики, которую и человек не может воплотить читаемо, не расчитывалось. Надо было это уточнить в первом сообщении