Comments 19
Спасибо за перевод! В дополнение к статье разрешите я оставлю здесь еще вот этот супермаленький проектик, где аналогичным образом на js очень хорошо «на пальцах» объясняется разбор lisp-подобного синтаксиса.
UFO just landed and posted this here
Я только слегка этой темы касался, поэтому могу фигню сморозить. Но я так понимаю — сперва исходник делится на лексемы, а потом токенизация на основе этого (хотя часто лекса и токен одно и тоже). Т.е. просматривается строка посимвольно: видим символ '=' или пробел, значит предыдущая лексема кончилась (так как проблел или = не может быть частью имени переменной), и начинаем собирать символы следующей лексемы.
github.com/1vanK/RecursiveDescentParser
А вообще перерывами читаю книгу linux-doc.ru/programming/assembler/book/compilers.pdf. Кажется достойной.
github.com/1vanK/RecursiveDescentParser
А вообще перерывами читаю книгу linux-doc.ru/programming/assembler/book/compilers.pdf. Кажется достойной.
Могу предположить, что для такой задачи придется сканировать код не один раз. Исходная строка должна анализироваться символ за символом и сравниваться с ключевыми словами (такими как например var, function), специальными символами (+, =, ;) и т.д., это поможет выявить структуры кода. Причем если мы обнаружили функцию, например, мы можем уже предположить что где-то далее по коду могут идти параметры и тело функции. В конечном счете, то, что останется, можно будет рассматривать как литералы.
UFO just landed and posted this here
UFO just landed and posted this here
Машина состояний. делал, работает отлично, главное правильно расписать все возможные переходы по состояниям правильно. В вашем случае без проблем всё обработается. Изначальное состояние — ожидание ключевого слова, далее соответственно будет ожидание имени переменной, далее спец-символа — знака равно, далее ожидание литерала. по знаку кавычки определяем, что это строковой литерал и идём далее до следующего знака кавычки.
Естественно переходов будем много, рисовал здоровенную диаграмму до того как начать прям вот реализовывать.
Естественно переходов будем много, рисовал здоровенную диаграмму до того как начать прям вот реализовывать.
Там все очень просто — вы смотрите начальный символ токена и для него вызываете соответствующее правило — так для токена начинающегося с цифры вызывается правило обработки чисел, для токена начинающегося с буквы или прочерка вызывается правило считывания имени. Как только правило встретит неподходящий символ (например пробел или, в вашем случае — знак равенства) оно свернет все что успело выгрести из входного текста в соответствующий ему (правилу) нетерминал и завершится. Далее лексер исходя из того на каком символе остановилось отработавшее правило (например мы встретили знак равенства) будет искать подходящее правило уже для него. И в нашем случае это будет правило «оператор». Оно проверит просто ли там равно или == или => итд — то есть все варианты оператора начинающегося с =. И свернет уже его)
Жаль Марико не различает интерпретацию и компиляцию
Это в том числе потому, что различие между ними в реальной жизни стирается.
Вот V8 — компилятор или интерпретатор?
Вот V8 — компилятор или интерпретатор?
«Интерпретатор компилирующего типа» — так подобное называли в книгах 80-х. Это когда код компилируется, но результат компиляции не сохраняется для повторного использования и удаляется после завершения работы.
На выходе в исполнение уходит некоторый байткот с оптимизациями, поэтому JIT-компиляция. В данном случае преобразования кода во что-то совсем низкоуровневое и более близкое к железу не происходит.
UFO just landed and posted this here
UFO just landed and posted this here
Sign up to leave a comment.
Как быть* компилятором — создание компилятора на JavaScript