Comments 13
Честно? Не стоило вам создавать библиотеку ))) Не разобравшись с темой. Тот же лексический анализ гораздо более эффективно решается одной регуляркой с группами в которых регулярки под каждый токен, а не тупое разбивание всего на пробелы.
Классический лексический анализ в языках программирования делается безо всяких регулярок.
Пихать регулярки в этот процесс можно разве что от незнания, как работать с байтами
Пихать регулярки в этот процесс можно разве что от незнания, как работать с байтами
Если вы имеете ввиду конечные автоматы, то они работают еще медленней чем регулярки. Неоднократно пытался переписать свои лексеры на них. (я говорю про их реализацию в js)
Я с вами полностью согласен, хороший компилятор (как и его части), это и есть — конечный автомат.
В том случае, если есть конкретно поставленный язык.
Мое решение — больше подходит для динамического, быстрого описания языка, что может быть полезным, если библиотека языка, который используется в поставленной задаче, еще не был написан для веба ранее.
В том случае, если есть конкретно поставленный язык.
Мое решение — больше подходит для динамического, быстрого описания языка, что может быть полезным, если библиотека языка, который используется в поставленной задаче, еще не был написан для веба ранее.
Согласен ( по поводу одной регулярки :) ), вы подали мне идею — перед парсингом, генерировать единую регулярку, используя ранее описанные группы.
Тогда, можно стать на шаг ближе, к генерированию настраиваемого, конечного автомата.
Тогда, можно стать на шаг ближе, к генерированию настраиваемого, конечного автомата.
github.com/angrycoding/regexp-lexer/blob/master/index.js вот посмотрите, мой вариант универсального токенайзера. Здесь пример использования: github.com/MegafonWebLab/histone-javascript/blob/master/src/parser/Parser.js
Мне вот интересно, а что это за метод парсинга такой? Можно подробнее как то либо в комментариях, либо статьей. Я то просто использую рекурсивный спуск, остальное как то не зашло. Не врубился. А то что описали вы — выглядит интересно.
Мне вот интересно, а что это за метод парсинга такой? Можно подробнее как то либо в комментариях, либо статьей. Я то просто использую рекурсивный спуск, остальное как то не зашло. Не врубился. А то что описали вы — выглядит интересно.
Если верить википедии, то у меня, тоже своего рода «Метод рекурсивного спуска»
ru.wikipedia.org/wiki/%D0%9C%D0%B5%D1%82%D0%BE%D0%B4_%D1%80%D0%B5%D0%BA%D1%83%D1%80%D1%81%D0%B8%D0%B2%D0%BD%D0%BE%D0%B3%D0%BE_%D1%81%D0%BF%D1%83%D1%81%D0%BA%D0%B0
А конкретнее, его реализация, под названием «Парсер с возвратом»
Только у меня, если ни одно правило не применимо к токену, то он пропускается.
По этому, он гарантирует завершение.
В моей реализации, правила — это последовательности (токенов, других правил, конкретных значений)
Например, у нас есть правило, определяющее «Определение переменной», оно состоит из последовательности токенов: Тип, Идентификатор, знак равно, значение, разделитель(например точка с запятой)
Если проверяемый токен имеет тип — «Тип», то мы проверяем следующий токен на совпадение с типом — «Идентификатор».
Если типы не сошлись, то мы пишем в стек ошибку «Unexpected Identificator» + место в source-map
Если другое правило подошло к стартовому токену, то стек очищается, иначе в коллбэк улетает синтаксическая ошибка, т.к. у проверяемого токена, наиболее вероятный нетерминал — «Определение переменной»
ru.wikipedia.org/wiki/%D0%9C%D0%B5%D1%82%D0%BE%D0%B4_%D1%80%D0%B5%D0%BA%D1%83%D1%80%D1%81%D0%B8%D0%B2%D0%BD%D0%BE%D0%B3%D0%BE_%D1%81%D0%BF%D1%83%D1%81%D0%BA%D0%B0
А конкретнее, его реализация, под названием «Парсер с возвратом»
Только у меня, если ни одно правило не применимо к токену, то он пропускается.
По этому, он гарантирует завершение.
В моей реализации, правила — это последовательности (токенов, других правил, конкретных значений)
Например, у нас есть правило, определяющее «Определение переменной», оно состоит из последовательности токенов: Тип, Идентификатор, знак равно, значение, разделитель(например точка с запятой)
Если проверяемый токен имеет тип — «Тип», то мы проверяем следующий токен на совпадение с типом — «Идентификатор».
Если типы не сошлись, то мы пишем в стек ошибку «Unexpected Identificator» + место в source-map
Если другое правило подошло к стартовому токену, то стек очищается, иначе в коллбэк улетает синтаксическая ошибка, т.к. у проверяемого токена, наиболее вероятный нетерминал — «Определение переменной»
Стесняюсь спросить, а если в строковую константу засунуть целое предложение, вы его тоже разобьёте на токены, выкинув пробелы между словами?
Sign up to leave a comment.
Пятница программиста, или как я писал библиотеку для лексического и синтаксического анализа кода