Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 18

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

«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 минут, а про разочарование от ожидания внятного продолжения.
Поскольку продолжения не анонсировано, то и разочарования не будет.
Продолжение будет, определенно. Идея была в том, чтобы публиковать отдельные фрагменты «руководства» (назовем это так) на хабре, получая обратную связь. Но теперь я для себя выяснил, что разумнее будет написать здесь, спустя время, уже о выходе полного и окончательного результата :)
НЛО прилетело и опубликовало эту надпись здесь
Это понятно. Но я говорю о результате в духе «книга ушла в печать» :)
Продолжайте. Очень интересно получилось про SSA. Интересно, что будет дальше. Преобразования над SSA?
НЛО прилетело и опубликовало эту надпись здесь

Если будет хотя бы сравнение, как можно сделать то, что Вас написано, с помощью готовых лексеров/парсеров (в питоне есть 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
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации