Здравствуйте, Sinclair, Вы писали:
S>Непонятно, при чём тут словари.
Для сопоставления инструкции на ее код и тому подобное. Я не очень понимаю смысл жестко хардкодить кучу методов вроде writeLoadInstructionToStream и т.д. Но это ладно, вкусовщина.
S>В итоге 3/4 курса студенты будут заниматься нудным выпиливанием лобзиком по вазелину, и только 1/4 — собственно компиляцией.
Да не будет там выпиливания лобзиком по вазелину.
S>Если бы у нас было всё время мира — да, можно всё пилить с нуля. Но у нас — 1 семестр, и это не единственный предмет в семестре. Положа руку на сердце: вы напишете с нуля компилятор небольшого языка с кодогенерацией и статической верификацией корректности за 32 часа?
Да, напишу. Правда без статической верификации корректности, этим никогда не занимался. Мне когда на практике такие задачи попадаются, естественно никто время на это не выделяет и не ставит задачу написания DSL. Но приходилось этим заниматься в трех разных конторах, навык оказался полезным.
S>Ну, вот мы их и обучаем. Причём в реальном производстве никогда они не будут с нуля ни токенайзер, ни парсер, ни кодогенератор писать. Бессмысленная затея. Значит, и навыки им нужны больше похожие на то, что в жизни понадобится.
Что интересно — мне это реально понадобилось в реальном проекте, и я писал и токенайзер (примитивный, тупо сплитом строки по регэкспу), и парсер, и кодогенератор. Причем на время и именно что с нуля. Язык, который пришлось парсить — 1С, естественно очень ограниченное подмножество
. Некоторые таланты блин в базу зафигачили 1С выражение как строку. Тупо логическое выражение с приоритетом, но там тысячи переменных со скобками и сотни функций, и вот мне требовалось повторить логику, но в более чем тысячу раз быстрее, ибо если реюзать функцию на 1С оригинальную, расчет займет много лет при полной загрузке всех серверов
. Как пример просто. Так еще доводилось DSL писать уже на текущем языке, чтоб можно было описывать уравнения на миллионы переменных в виде близкой к математической записи и затем из этого интерпретировать в различные решатели систем уравнений. Проект правда через года 3 всеж помер, из за смены языка программирования на питон, но тем не менее какое то время доводилось писать и классический интерпретатор, хоть и без токенайзера и парсера, ибо DSL была на том же языке сделана, тупо переопределены операторы были и был набор классов определенных и функций их конструирования, далее тупо обход AST и интерпретация, причем еще и с оптимизациями некоторыми. Написать компилятор тоже не составило б труда, но не было необходимости.
Навык написания как минимум интерпретаторов и кодогенератора, наколенный — позволяет сэкономить кучу времени, и если задачи типовые — реюзать и ОЧЕНЬ быстро реагировать на изменения требований. Тупо добавить потом пару строчек, нажать билд и деплой — и все. А не хреначить один и тот же копипастный код из проекта в проект.
S>Вот у нас студенты как раз учатся делать это элегантно — на PEG-грамматиках.
Нашел этот курс охрененный! Блин, его с ютуба удалили, потому и потерял. На всякий случай еще и сюда —
http://www.infocobuild.com/education/audio-video-courses/computer-science/CS164-Spring2012-Berkeley/lecture-01.html. Ключевые слова CS 164 Ras Bodik Spring 2012. Здесь именно упор на написание DSL, кажется всеж этот, надо будет пересмотреть, а то я забыл все нафик. Или посмотреть что поновее было б неплохо, но именно от этого курса я был в свое время в восторге и этот курс много заставил переосмыслить. Надо б блин сохранить как нибудь, а то ведь удалят нафик снова ...