Pull to refresh

Comments 18

UFO landed and left these words here
Собственно, Вы сами ответили уже на свой вопрос. Зачем «целая куча терминов для одного и того же»? «Транспилятор» это тот же транслятор. Ведь ничего же нового нет в такого рода трансляции. Вот здесь имеется любопытная дискуссия на тему: news.ycombinator.com/item?id=15154994
UFO landed and left these words here
Конечно же является. Вот определения из двух известных учебников:

«A compiler is a tool that translates software written in one language into
another language». (K. Cooper. L Torczon. Engineering a Compiler)

«Compilers are software systems that translate programs written in higher-level languages into equivalent programs in object code or machine language for execution on a computer». (Steven Muchnick. Advanced Compiler Design and Implementation).

Очередная статья для начинания деланья компиляторов, но почему все они так недалеко заходят? Как только начинаются менее тривиальные вещи, чем семантический анализ, и всё, цикл оборвался.
Задумано ли что-то серьёзное из этой статьи или автор честно ограничится введением?
Я думаю, не стоит даже упоминать том, что создавать компиляторы — дело непростое. За 15 минут вас никто не сможет научить это делать. Тут у нас, скорее, ситуация в духе знаменитой заметки Teach Yourself Programming in Ten Years П. Норвига. Поэтому специалисты по компиляторам и ценятся так высоко, правильно?

Есть и еще один момент. Компиляторы это чрезвычайно широкая область. В большинстве случаев ее и не нужно досконально изучать. Необходимо определить свою нишу. Например, в последнее время очень популярна тема создания собственных DSL, в том числе и на основе source-to-source подхода. Еще один популярный аспект — создание компилятора с порождением целевого кода для LLVM или подобного готового backend'а. Здесь надо понимать, хотя бы, что такое SSA. Теперь давайте вернемся к моей 15-минутной заметке. А ведь тут уже изложены на простых примерах как source-to-source-подход, так и SSA.

Я и сам немного подустал от многочисленных легковесных введений в компиляторостроение. Но мне захотелось попробовать свои силы: как много я смогу доходчиво рассказать в пределах условных 15 минут. Мне показалось, что можно разработать цикл 15-минутных историй по разным моментам, связанным с данной тематикой. И эти истории помогут читателям с разбором серьезных материалов. О них — ниже.

Итак, вы хотите серьезного подхода. Тогда добро пожаловать на вики-страничку.
Речь не про 15 минут, а про разочарование от ожидания внятного продолжения.
Поскольку продолжения не анонсировано, то и разочарования не будет.
Продолжение будет, определенно. Идея была в том, чтобы публиковать отдельные фрагменты «руководства» (назовем это так) на хабре, получая обратную связь. Но теперь я для себя выяснил, что разумнее будет написать здесь, спустя время, уже о выходе полного и окончательного результата :)
UFO landed and left these words here
Это понятно. Но я говорю о результате в духе «книга ушла в печать» :)
Продолжайте. Очень интересно получилось про SSA. Интересно, что будет дальше. Преобразования над SSA?
UFO landed and left these words here

Если будет хотя бы сравнение, как можно сделать то, что Вас написано, с помощью готовых лексеров/парсеров (в питоне есть ply, sly), и что писать парсеры самостоятельно — не лучшая идея, было бы замечательно. Ведь компиляторы — действительно сложная штука! И если надо по-быстрому набросать свой DSL, кто-то может пойти на хабр, найти подобный туториал и нафигачить все с нуля. Гораздо ценнее было бы почитать, что делать с ast после парсинга. Таких статей, как мне показалось, значительно меньше
P.s. навеяно болью переписывания самописного парсера (предыдущим коллегой) на ply

Обратите внимание, что моя заметка, по большому счету, именно о backend. Как раз по той причине, что статей на эту тему «значительно меньше».

Лексический/синтаксический анализ вы можете найти в любом учебнике. Это самая формализованная, проверенная часть компилятора. Тем не менее, действительно, полезно еще раз обратить внимание на это, что кроме lex/yacc существуют более удобные, современные средства: PEG, комбинаторы. Вот пример игрушечного компилятора, который сделан с помощью моей библиотеки raddsl: github.com/true-grue/PigletC
«A compiler is a tool that translates software written in one language into
another language». (K. Cooper. L Torczon. Engineering a Compiler)

Т.е. достаточно sed, grep и awk и можно писать компилятор.

Вот бы кто-нибудь компилятор из PHP (для основных конструкций работы с массивами и строками) в С сделал.
А то мной было подмечно, что код из PHP перекладывается в С почти без усилий.

По-моему если писать подобное 15-минутное введение — то было бы весьма неплохо сделать прототип с помощью широко известных в узких кругах инструментов, вроде lex/bison.
А то банальный парсер грамматики пробуют писать все, и даже до конечного автомата дело доходит — но вот в реальной жизни в подавляющем большинстве случаев удобнее использовать готовый парсер, чем городить свой. Особенно с точки зрения поддержки синтаксиса в будущем и его расширяемости (добавить правило из пяти строчек в бизоновский исходник всё же проще, чем перелопатить тысячу строк готового ДКА).
Да, такие "вводные" уже есть, но что-то кроме dragon book я их особо то и не видел.
Лучше, если простых примеров будет больше!

Я выше уже написал по поводу lex/yacc/bison. Обратите внимание, что в современных «промышленных» компиляторах (clang, gcc и проч.) такого рода инструментарий не используется. А используется там традиционный подход на основе рекурсивного спуска.

Среди современных генераторов парсеров, удобных для начинающих, я бы выделил, например, Ohm: nextjournal.com/dubroy/ohm-parsing-made-easy
Sign up to leave a comment.

Articles