Аннотация:
В статье описывается реализация компилятора языка программирования Mini C на базе Nitra (под платформу .Net). Mini C — это упрощенная версия языка C. В статье описывается все этапы реализации языка от создания парсера, до генерации MSIL. И сам язык и данное описание созданы для демонстрации того как разрабатывать языки программирования на Nitra. Nitra — это средство разрабоки ЯП (language workbench). Nitra можно использовать для создания языков программирования с расширяемыми синтаксисом и семантикой, а так же языков предметной области (DSL).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Реализация языка программирования Mini C на Nitra
Я не в теме, но подход нитры мне кажется слегка переусложнённым.
В нитре три внутренних представления:
1) синтаксис
2) AST
3) целевая модель
и соответственно, минимум пять языков (3 языка описания и 2 языка трансформации)
Если оставить только два представления:
1) исходное;
2) конечное;
то понадобиться всего три формализма:
1) для описания синтаксисов (EBNF)
2) для описания объектных моделей (тут какой-нибудь язык запросов для ОО-СУБД)
3) язык преобразования (типа XSLT)
(ну, ещё может пригодиться язык навигации по дереву EBNF типа XPath)
UPD: Можно пойти ещё дальше.
Нам надо одну последовательность битов (исходный текст) преобразовать в другую (бинарный код).
Чем у нас описывают последовательности битов? ASN.1 XER.
Таким образом, нужно всего два формализма — этот и формализм для преобразования.
Здравствуйте, Arsen.Shnurkov, Вы писали: AS>В нитре три внутренних представления: AS>1) синтаксис AS>2) AST AS>3) целевая модель
К сожалени, ока только два: синтаксис и AST. По уму надо для каждого уровня делать свои языки. Но пока на это нет ресурсов. Так что вместо целевой модели приходится использовать API вроде CCI и писать код на языке общего назначения чтобы сгенерировать тот же MSIL. И это намного сложнее нежели использовать трансформацию языков.
AS>и соответственно, минимум пять языков (3 языка описания и 2 языка трансформации)
Вот чего нет, того нет. Есть один язык описания синтаксиса, одни язык описания АСТ-а, один язык трасформации. Ну, с натяжкой еще есть язык зависимых свойств, который позволяет вести расчеты на АСТ. Никаких двух языков трансформации пока что нет. И трех описания тоже.
Собственно в концепции говорится о том, что все должно свестись к трансформации между языками. Мы берем исходный зык. Получаем для него типизированный АСТ и потом переписываем его в другой язык, более низкоуровневый. А по этому языку уже генерация должна стать тривиальным занятием. И языков таких может быть более одного, так как проще делать преобразования по уровням. Чем меньше разница абстракции между языками, тем проще трансформация.
AS>Если оставить только два представления: AS>1) исходное; AS>2) конечное;
AS>то понадобиться всего три формализма: AS>1) для описания синтаксисов (EBNF)
Вот у нас и есть аналогичный язык описывающий синтаксис и Дерево Разбора (ДР) одним махом.
AS>2) для описания объектных моделей (тут какой-нибудь язык запросов для ОО-СУБД)
Это какие-то невнятные мечты. Есть АСТ и символы. Вот их нужно как-то описывать. Запросы тут никаким боком. Это скорее аналог ДМЛ или описания классов в ООЯ.
AS>3) язык преобразования (типа XSLT)
Вот это и есть наш язык трансформации из ДР в АСТ.
AS>(ну, ещё может пригодиться язык навигации по дереву EBNF типа XPath)
А зачем он нужен?
Мне кажется ты не до конца разобрался в том, что есть в Нитре.
ЗЫ
Есть такое мудрое изречение Сталина:
Есть логика намерений и логика обстоятельств, и логика обстоятельств сильнее логики намерений.
Так вот мечтать можно о чем угодно, но когда ты дойдешь до дела, то все твои мечты упрутся в суровые обстоятельства. Вот подобные фантазии тоже разбиваются о суровую действительность.
При создании инструмента типа Нитры есть множеств взаимно противоречащих задач. Одна из них, например, иметь единый код типизации для целых групп родственных языков (C#, Nemerle, VB, ...). Так вот АСТ и Дерево Разбора (ДР) — это разные вещи. Дерево разбора для каждого языка уникально. АСТ по большей части одинаков.
Язык трансформации и ДР в АСТ у нас получился не очень интитивным, но пока без него нельзя. Вот когда будем делать новый Немерл, то тот факт, что у Немерла единый синтаксис позволит там сделать описание макросов, которые скроит трансформацию и для большого набора случаев позволит описывать ДР и трансформацию в АСТ одной конструкцией.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Реализация языка программирования Mini C на Nitra
VD> все должно свестись к трансформации между языками.
Все языки предлагаю описывать одинаково, при помощи ASN.1 XER.
Этапы трансформации тогда тоже будут описываться одним и тем же способом.
VD> Это какие-то невнятные мечты.
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>Все языки предлагаю описывать одинаково, при помощи ASN.1 XER.
На XER это нужно? (простите, не удержался)
AS>Этапы трансформации тогда тоже будут описываться одним и тем же способом.
Может я плохо представляю себе что такое ASN.1 XER, но мне кажется это совершенно бессмысленное предложение. Вообще не понимаю каким боком тут форматы кодирования воде ASN.1 тем более зачем тут нужен XML. "XER" ведь, как я понима, это ХМЛ-версия ASN.1.
У нас нет проблем передачи данных по сети. Наши данные — это аннотированный АСТ, дерево разбора. На фиг нам спускаться к битам и байтам?
VD>> Это какие-то невнятные мечты.
AS>ну да, сперва добиться
Сперва не плохо было бы разобраться. Твое сообщение говорит о том, что ты этого не сделал или сделал очень поверхностно. А уж предложение использовать ASN.1 XER вообще звучит феерично.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Реализация языка программирования Mini C на Nitra
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>Именно. Всё что ты сделал — прочитал какую-то аннотацию.
Вообще-то не аннотацию, а вводную статью. Ну, и в разговорах не раз видел.
Открой мне глаза, если я заблуждаюсь. Объясни зачем мне может быть нужен этот формат.
AS>Две возможности: AS>1) Чтобы сгенерировать двоичный код.
А зачем мне генерировать двоичный код? Для генерации исполнимого кода есть специальные API. Для дотнета это CCI Metadata, Mono cecil. Для Яыв тоже свой есть. Для нэйтив: LLVM API или просто генерация C-кода.
AS>2) как бонус — входной файл тоже можно описывать как бинарный и унифицировать преобразования.
Дык не нужны преобразования бинарных данных. Вот сделать DSL для того же MSIL-а смысл есть, хотя и не очень большой. Это позволило бы сделать код преобразования из АСТ в него более декларативным и высокоуровневым, позволило бы абстрагироваться от API через которое идет генерация. А использовать тут какой-то язык описания форматов попросту не нужно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Кроме того, любой созданный на Nitra язык является автоматически расширяемым. Так что к нашему Mini C можно легко приделать макросы в стиле Nemerle или расширить его какими-то новыми конструкциями.
Тут просится ещё небольшая статья об этом или простой пример хотя бы из форума.
Nitra скрывает от разработчика языка все сложности, связанные с разработкой движка IDE, и позволяет, не меняя исходного кода языка, получать улучшения от развития Nitra.
Было бы полезно разбавить текст картинками и показать эти возможности, а не только писать о них.
Кроме того, любой созданный на Nitra язык является автоматически расширяемым. Так что к нашему Mini C можно легко приделать макросы в стиле Nemerle или расширить его какими-то новыми конструкциями.
_NN>Тут просится ещё небольшая статья об этом или простой пример хотя бы из форума.
Nitra скрывает от разработчика языка все сложности, связанные с разработкой движка IDE, и позволяет, не меняя исходного кода языка, получать улучшения от развития Nitra.
_NN>Было бы полезно разбавить текст картинками и показать эти возможности, а не только писать о них.
Сейчас доделаю поддержку для нитры и напишу об этом статейку с картинками и анимированными гифками.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Реализация языка программирования Mini C на Nitra
Кроме того, любой созданный на Nitra язык является автоматически расширяемым. Так что к нашему Mini C можно легко приделать макросы в стиле Nemerle или расширить его какими-то новыми конструкциями.
_NN>Тут просится ещё небольшая статья об этом или простой пример хотя бы из форума.
Добавил ссылку в статью.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Реализация языка программирования Mini C на Nitra
VD> Для генерации исполнимого кода есть специальные API.
Вызовы этих API — это императивный подход, а не декларативный.
Допустим, ты описал генерацию кода в виде программы на C#.
Всё, эта работа для человечества потеряна, так как никто кроме тебя с этим кодом возиться/разбираться/улучшать не будет.
А был бы он декларативным, то можно было бы с ним что-нибудь поделать.
AS>>2) как бонус — входной файл тоже можно описывать как бинарный и унифицировать преобразования.
VD> Дык не нужны преобразования бинарных данных.
У нас есть исходный бинарный файл, конечный бинарный файл и некоторое количество промежуточных представлений в памяти (тоже, кстати бинарных)
Используя преобразования одного в другое, можно было бы сделать альтернативную технологию.
Re: Реализация языка программирования Mini C на Nitra
Здравствуйте, VladD2, Вы писали:
VD>Реализация Mini C позволяет не только получить полноценный компилятор урезанного C, но также в автоматическом режиме сгенерировать плагин к VS. Этот плагин предоставляет базовые возможности IntelliSense: автодополнение при вводе, подсветку синтаксиса и символов, навигацию по символам
Отладчик в студии будет работать? Или для этого нужно доработать плагин?
Re[2]: Реализация языка программирования Mini C на Nitra
Здравствуйте, ylab, Вы писали:
Y>Отладчик в студии будет работать? Или для этого нужно доработать плагин?
Тут вопрос о каком отладке чего идет речь. Чтобы работал отладчик в конечных скопмпилированных программах, нужно при генерации кода делать дополнительные действия по созданию pdb. В примере MiniC этого не делается (насколько я помню).
Если речь об отладке самого компилятора, то — да будет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
(простите, не удержался)
