Сообщение Re[4]: Nemerle & Nitra от 14.01.2017 22:36
Изменено 14.01.2017 22:44 VladD2
Re[4]: Nemerle & Nitra
Здравствуйте, Kolesiki, Вы писали:
K>К примеру, говоря о CCI: "Скорее всего, лучше заменить его на код из Roslyn" — зачем им это знать?
K>Затем, что это одна из актуальных задач. Сейчас бэкэнд на CCI, но надо попробовать сделать бэкэнд основанный на Roslyn. Это должно быть не очень сложно, так как в Roslyn тупо откопипастили CCI.
K>Моё мнение — нужно вообще сторониться Рослин-кода и взять какой-нибудь Cecil (если его возможностей достаточно).
Это потому что ты незнаком с некоторыми деталями.
Дело в том, что МС расплодил кучу платформ и только Roslyn-овский компилятор позволяет поддерживать их все. Даже у CCI есть проблемы. А у Cecil их еще больше, плюс откровенные баги, которые могут возрождаться (отказываться после исправления).
Мы спроектировали все так, что в принципе можно сделать несколько бэкэндов. Наличие Roslyn-вского бэкэнда никак не мешает наличию CCI-го и Cecil-вского. Да хоть LLVM-го или Java-ного. Но Roslyn-вский дает поддержку определенных платформ, плюс в из кода Рослина можн узнать некоторые решения при генерации кода (которые не тривильны), так что изучение Roslyn-а по любому полезно. Плюс одно может быть кому-то интересно для самообразования (повышения скилов).
K>Т.е. на басурманский лучше переводить только те вещи, в которых мы сами уверены и которые будут заметно полезны. Вот стадии компиляции я прочёл с большим интересом, им тоже этот раздел понравится.
Ну, может у меня на моей колокольни глаз замылен и я вижу все не так как следует, но по-моему, я описал как раз те вопросы которые должны возникнуть у потенциальных разработчиков. Я, как раз, отталкивался от вопросов которые мне уже задавали (в том числе на https://gitter.im/rsdn/nemerle).
K>Нет, речь не о том и не в такой форме. Мы говорим об "абстрактном" компиляторе, который вынужден проходить какие-то стадии и что-то делать. У тебя это расписано. Но для них (остального мира) мы должны объяснить наглядно, разжёвывая каждую стадию и поясняя, что за нас уже сделано самой Нитрой (или планируется). Milestone — это уже конкретные этапы конкретного продукта, кратко расписанные для удобочитаемости.
Честно говоря все равно не понял в чем разница. Milestone — это и есть разжевывание.
K>Кратко, вот в том списке стадий компиляции нужно пометить жирным, что Нитра должна делать за нас (всё, и сделанное, и планируемое),
Нитра — это инструмент. Она за нас ничего не делает. Она предоставляет средства реализации. Ну, как C# или C++. Чтобы понять, что она предоставляет лучше прочесть статьи по ней. К сожалению они тоже все на русском и ты сам тут рядом предъявлял к ним претензии. Возможно поможет чтение Реализация языка программирования Mini C на Nitra
K>а уже эти жирные части раскрасить синим — сделанные, красным — планируемые. Если какая-то фича — сложная и сделанная наполовину, не грех её разбить на пару предложений и выделить не сделанное.
Говорить о сделано / не сделано можно только в рамках проектов. Вот в проекте Cx# (он же CSharp.Grammar) коне что сделано. И я описал что. Можно по подробнее расписать этот и другие проекты. Но боюсь, что здесь детализация тоже же будет размывать картину.
K>Вот тогда один взгляд на список сразу даст понимание состояния проекта. Да, альтернативы туда тоже нужно внести, может даже блок-схемой: разные бэкенды, разные платформы и т.п.
Честно говоря, по-моему, для того чтобы дело начало двигаться важно не понимание состояния проекта, а чтобы люди начали мне помогать. Другими словами, чтобы люди из созерцателей превратились в помошников — комьюнити развивающее язык.
Я уже несколько раз закидывал идею начала работы над языками, но все хлапали глазки и даже не вступали в дискуссию. А когда дискуссия спонтанно завязалась на https://gitter.im/rsdn/nemerle, быстро выяснилось, что она перешла в обсуждение где найти по больше фич, которые желательно впихнуть в язык. Вот только я и сам знаю что можно впихнуть я язык. А проблема не в этом, а в том, чтобы начать этот язык равивать.
Даже скажу больше. Проблема в том, чтобы люди начали знакомиться с самой Нитрой. В процессе я как-нибудь объяснил бы детали. И план я тоже могу составить. Это не проблема.
За все время откликнулся только один человек Василий Кириченко. Он даже сделал тот самый пример Mini-C на котором я убедился, что человек со стороны вполне может освоить Нитру. Но потом он тихо исчез. Было еще 2-3 человека которые дальше разговоров не пошли.
Подозревают, что есть какие-то технические и/или психологические аспекты препятствующие активном включению в проект. Но, к сожалнеию нет даже простого фитбэка. Так что я даже не могу выявить эти поблемы.
K>Ну вот, список стадий уже есть! Ты даже написал про уже сделанные модули, но они нужны в самом списке, а не подстрочником.
Я не понимаю, что такое подстрочник. Включать их в сам список — это значит еще больше его раздувать. По-моему, все и так довольно очевидно. В Cx# сделано все до типизации тел методов. Но многое из сделанного еще нужно допиливать напильником (нужна куча дополнительных проверок соответствии спецификации). А не сделаны типизация тел и кодогенерация и сериализация сборок на диск.
K>Вопрос не в тему: про объединении C+#x$% и Nemerle-2 ты упомянул, что "АСТ можно вынести в общий модуль" — это как и зачем??
Ну, вот как-бы об этом я и писал. Вся первая часть этому и была посвящена. Но ты сказал, что это не важные детали, а выходит, что то ли не прочел, то ли не понял.
K>АСТ — это же структура в памяти, причём у каждого языка — своя (несмотря на подавляющую схожесть). Рантаймовую структуру вынести в модуль??
K>К примеру, говоря о CCI: "Скорее всего, лучше заменить его на код из Roslyn" — зачем им это знать?
K>Затем, что это одна из актуальных задач. Сейчас бэкэнд на CCI, но надо попробовать сделать бэкэнд основанный на Roslyn. Это должно быть не очень сложно, так как в Roslyn тупо откопипастили CCI.
K>Моё мнение — нужно вообще сторониться Рослин-кода и взять какой-нибудь Cecil (если его возможностей достаточно).
Это потому что ты незнаком с некоторыми деталями.
Дело в том, что МС расплодил кучу платформ и только Roslyn-овский компилятор позволяет поддерживать их все. Даже у CCI есть проблемы. А у Cecil их еще больше, плюс откровенные баги, которые могут возрождаться (отказываться после исправления).
Мы спроектировали все так, что в принципе можно сделать несколько бэкэндов. Наличие Roslyn-вского бэкэнда никак не мешает наличию CCI-го и Cecil-вского. Да хоть LLVM-го или Java-ного. Но Roslyn-вский дает поддержку определенных платформ, плюс в из кода Рослина можн узнать некоторые решения при генерации кода (которые не тривильны), так что изучение Roslyn-а по любому полезно. Плюс одно может быть кому-то интересно для самообразования (повышения скилов).
K>Т.е. на басурманский лучше переводить только те вещи, в которых мы сами уверены и которые будут заметно полезны. Вот стадии компиляции я прочёл с большим интересом, им тоже этот раздел понравится.
Ну, может у меня на моей колокольни глаз замылен и я вижу все не так как следует, но по-моему, я описал как раз те вопросы которые должны возникнуть у потенциальных разработчиков. Я, как раз, отталкивался от вопросов которые мне уже задавали (в том числе на https://gitter.im/rsdn/nemerle).
K>Нет, речь не о том и не в такой форме. Мы говорим об "абстрактном" компиляторе, который вынужден проходить какие-то стадии и что-то делать. У тебя это расписано. Но для них (остального мира) мы должны объяснить наглядно, разжёвывая каждую стадию и поясняя, что за нас уже сделано самой Нитрой (или планируется). Milestone — это уже конкретные этапы конкретного продукта, кратко расписанные для удобочитаемости.
Честно говоря все равно не понял в чем разница. Milestone — это и есть разжевывание.
K>Кратко, вот в том списке стадий компиляции нужно пометить жирным, что Нитра должна делать за нас (всё, и сделанное, и планируемое),
Нитра — это инструмент. Она за нас ничего не делает. Она предоставляет средства реализации. Ну, как C# или C++. Чтобы понять, что она предоставляет лучше прочесть статьи по ней. К сожалению они тоже все на русском и ты сам тут рядом предъявлял к ним претензии. Возможно поможет чтение Реализация языка программирования Mini C на Nitra
Автор: VladD2
Дата: 12.01.17
.Дата: 12.01.17
K>а уже эти жирные части раскрасить синим — сделанные, красным — планируемые. Если какая-то фича — сложная и сделанная наполовину, не грех её разбить на пару предложений и выделить не сделанное.
Говорить о сделано / не сделано можно только в рамках проектов. Вот в проекте Cx# (он же CSharp.Grammar) коне что сделано. И я описал что. Можно по подробнее расписать этот и другие проекты. Но боюсь, что здесь детализация тоже же будет размывать картину.
K>Вот тогда один взгляд на список сразу даст понимание состояния проекта. Да, альтернативы туда тоже нужно внести, может даже блок-схемой: разные бэкенды, разные платформы и т.п.
Честно говоря, по-моему, для того чтобы дело начало двигаться важно не понимание состояния проекта, а чтобы люди начали мне помогать. Другими словами, чтобы люди из созерцателей превратились в помошников — комьюнити развивающее язык.
Я уже несколько раз закидывал идею начала работы над языками, но все хлапали глазки и даже не вступали в дискуссию. А когда дискуссия спонтанно завязалась на https://gitter.im/rsdn/nemerle, быстро выяснилось, что она перешла в обсуждение где найти по больше фич, которые желательно впихнуть в язык. Вот только я и сам знаю что можно впихнуть я язык. А проблема не в этом, а в том, чтобы начать этот язык равивать.
Даже скажу больше. Проблема в том, чтобы люди начали знакомиться с самой Нитрой. В процессе я как-нибудь объяснил бы детали. И план я тоже могу составить. Это не проблема.
За все время откликнулся только один человек Василий Кириченко. Он даже сделал тот самый пример Mini-C на котором я убедился, что человек со стороны вполне может освоить Нитру. Но потом он тихо исчез. Было еще 2-3 человека которые дальше разговоров не пошли.
Подозревают, что есть какие-то технические и/или психологические аспекты препятствующие активном включению в проект. Но, к сожалнеию нет даже простого фитбэка. Так что я даже не могу выявить эти поблемы.
K>Ну вот, список стадий уже есть! Ты даже написал про уже сделанные модули, но они нужны в самом списке, а не подстрочником.
Я не понимаю, что такое подстрочник. Включать их в сам список — это значит еще больше его раздувать. По-моему, все и так довольно очевидно. В Cx# сделано все до типизации тел методов. Но многое из сделанного еще нужно допиливать напильником (нужна куча дополнительных проверок соответствии спецификации). А не сделаны типизация тел и кодогенерация и сериализация сборок на диск.
K>Вопрос не в тему: про объединении C+#x$% и Nemerle-2 ты упомянул, что "АСТ можно вынести в общий модуль" — это как и зачем??
Ну, вот как-бы об этом я и писал. Вся первая часть этому и была посвящена. Но ты сказал, что это не важные детали, а выходит, что то ли не прочел, то ли не понял.
K>АСТ — это же структура в памяти, причём у каждого языка — своя (несмотря на подавляющую схожесть). Рантаймовую структуру вынести в модуль??
Re[4]: Nemerle & Nitra
Здравствуйте, Kolesiki, Вы писали:
K>К примеру, говоря о CCI: "Скорее всего, лучше заменить его на код из Roslyn" — зачем им это знать?
K>Затем, что это одна из актуальных задач. Сейчас бэкэнд на CCI, но надо попробовать сделать бэкэнд основанный на Roslyn. Это должно быть не очень сложно, так как в Roslyn тупо откопипастили CCI.
K>Моё мнение — нужно вообще сторониться Рослин-кода и взять какой-нибудь Cecil (если его возможностей достаточно).
Это потому что ты незнаком с некоторыми деталями.
Дело в том, что МС расплодил кучу платформ и только Roslyn-овский компилятор позволяет поддерживать их все. Даже у CCI есть проблемы. А у Cecil их еще больше, плюс откровенные баги, которые могут возрождаться (отказываться после исправления).
Мы спроектировали все так, что в принципе можно сделать несколько бэкэндов. Наличие Roslyn-вского бэкэнда никак не мешает наличию CCI-го и Cecil-вского. Да хоть LLVM-го или Java-ного. Но Roslyn-вский дает поддержку определенных платформ, плюс в из кода Рослина можн узнать некоторые решения при генерации кода (которые не тривильны), так что изучение Roslyn-а по любому полезно. Плюс одно может быть кому-то интересно для самообразования (повышения скилов).
K>Т.е. на басурманский лучше переводить только те вещи, в которых мы сами уверены и которые будут заметно полезны. Вот стадии компиляции я прочёл с большим интересом, им тоже этот раздел понравится.
Ну, может у меня на моей колокольни глаз замылен и я вижу все не так как следует, но по-моему, я описал как раз те вопросы которые должны возникнуть у потенциальных разработчиков. Я, как раз, отталкивался от вопросов которые мне уже задавали (в том числе на https://gitter.im/rsdn/nemerle).
K>Нет, речь не о том и не в такой форме. Мы говорим об "абстрактном" компиляторе, который вынужден проходить какие-то стадии и что-то делать. У тебя это расписано. Но для них (остального мира) мы должны объяснить наглядно, разжёвывая каждую стадию и поясняя, что за нас уже сделано самой Нитрой (или планируется). Milestone — это уже конкретные этапы конкретного продукта, кратко расписанные для удобочитаемости.
Честно говоря все равно не понял в чем разница. Milestone — это и есть разжевывание.
K>Кратко, вот в том списке стадий компиляции нужно пометить жирным, что Нитра должна делать за нас (всё, и сделанное, и планируемое),
Нитра — это инструмент. Она за нас ничего не делает. Она предоставляет средства реализации. Ну, как C# или C++. Чтобы понять, что она предоставляет лучше прочесть статьи по ней. К сожалению они тоже все на русском и ты сам тут рядом предъявлял к ним претензии. Возможно поможет чтение Реализация языка программирования Mini C на Nitra
K>а уже эти жирные части раскрасить синим — сделанные, красным — планируемые. Если какая-то фича — сложная и сделанная наполовину, не грех её разбить на пару предложений и выделить не сделанное.
Говорить о сделано / не сделано можно только в рамках проектов. Вот в проекте Cx# (он же CSharp.Grammar) коне что сделано. И я описал что. Можно по подробнее расписать этот и другие проекты. Но боюсь, что здесь детализация тоже же будет размывать картину.
K>Вот тогда один взгляд на список сразу даст понимание состояния проекта. Да, альтернативы туда тоже нужно внести, может даже блок-схемой: разные бэкенды, разные платформы и т.п.
Честно говоря, по-моему, для того чтобы дело начало двигаться важно не понимание состояния проекта, а чтобы люди начали мне помогать. Другими словами, чтобы люди из созерцателей превратились в помошников — комьюнити развивающее язык.
Я уже несколько раз закидывал идею начала работы над языками, но все хлапали глазки и даже не вступали в дискуссию. А когда дискуссия спонтанно завязалась на https://gitter.im/rsdn/nemerle, быстро выяснилось, что она перешла в обсуждение где найти по больше фич, которые желательно впихнуть в язык. Вот только я и сам знаю что можно впихнуть я язык. А проблема не в этом, а в том, чтобы начать этот язык равивать.
Даже скажу больше. Проблема в том, чтобы люди начали знакомиться с самой Нитрой. В процессе я как-нибудь объяснил бы детали. И план я тоже могу составить. Это не проблема.
За все время откликнулся только один человек Василий Кириченко. Он даже сделал тот самый пример Mini-C на котором я убедился, что человек со стороны вполне может освоить Нитру. Но потом он тихо исчез. Было еще 2-3 человека которые дальше разговоров не пошли.
Подозревают, что есть какие-то технические и/или психологические аспекты препятствующие активном включению в проект. Но, к сожалнеию нет даже простого фитбэка. Так что я даже не могу выявить эти поблемы.
K>Ну вот, список стадий уже есть! Ты даже написал про уже сделанные модули, но они нужны в самом списке, а не подстрочником.
Я не понимаю, что такое подстрочник. Включать их в сам список — это значит еще больше его раздувать. По-моему, все и так довольно очевидно. В Cx# сделано все до типизации тел методов. Но многое из сделанного еще нужно допиливать напильником (нужна куча дополнительных проверок соответствии спецификации). А не сделаны типизация тел и кодогенерация и сериализация сборок на диск.
K>Вопрос не в тему: про объединении C+#x$% и Nemerle-2 ты упомянул, что "АСТ можно вынести в общий модуль" — это как и зачем??
Ну, вот как-бы об этом я и писал. Вся первая часть этому и была посвящена. Но ты сказал, что это не важные детали, а выходит, что то ли не прочел, то ли не понял.
K>АСТ — это же структура в памяти,
Ну и что что в памяти? У тебя объект — это тоже "структуры в памяти", но чтобы они были тебе же нужно описать классы? Вот и в АСТ нужно описать типы АСТ на освновании которых будут уже структуры в памяти создаваться (в рантайме). Все правила типизации описываются на этих структурах (т.е. на АСТ). И об этом я тоже сказал.
K>причём у каждого языка — своя (несмотря на подавляющую схожесть).
Опять таки и об этом я скзал. 80% таких структур будет одинаковыми (идентичными). Нет смысл описывать их для каждого языка. Уникальные вещи воде паттерн-матчинга — надо. Но кроме них есть еще куча общих вещей. На то он и AST. Первая буква в слове "AST" помнишь, что означает? Это — Abstract. На то он и абстракный, чтобы не зависит от конкретного языка.
K>Рантаймовую структуру вынести в модуль??
У тебя явно путанница между стадиями. АСТ — это рантайм структура компилятора, а не самого языка. Вот текст на языке разбирается и переводится (в памяти компилятора) в АСТ. На АСТ-е прозводятся вычисления и по аннотированному АСТ просзводится уже генерация кода (это упрощенно).
Я описал, что есть проект DotNetLang в котором и собран общий для всех языков АСТ. Уникальный АСТ будет в проектах конкретных языков. Но его будет не много.
K>К примеру, говоря о CCI: "Скорее всего, лучше заменить его на код из Roslyn" — зачем им это знать?
K>Затем, что это одна из актуальных задач. Сейчас бэкэнд на CCI, но надо попробовать сделать бэкэнд основанный на Roslyn. Это должно быть не очень сложно, так как в Roslyn тупо откопипастили CCI.
K>Моё мнение — нужно вообще сторониться Рослин-кода и взять какой-нибудь Cecil (если его возможностей достаточно).
Это потому что ты незнаком с некоторыми деталями.
Дело в том, что МС расплодил кучу платформ и только Roslyn-овский компилятор позволяет поддерживать их все. Даже у CCI есть проблемы. А у Cecil их еще больше, плюс откровенные баги, которые могут возрождаться (отказываться после исправления).
Мы спроектировали все так, что в принципе можно сделать несколько бэкэндов. Наличие Roslyn-вского бэкэнда никак не мешает наличию CCI-го и Cecil-вского. Да хоть LLVM-го или Java-ного. Но Roslyn-вский дает поддержку определенных платформ, плюс в из кода Рослина можн узнать некоторые решения при генерации кода (которые не тривильны), так что изучение Roslyn-а по любому полезно. Плюс одно может быть кому-то интересно для самообразования (повышения скилов).
K>Т.е. на басурманский лучше переводить только те вещи, в которых мы сами уверены и которые будут заметно полезны. Вот стадии компиляции я прочёл с большим интересом, им тоже этот раздел понравится.
Ну, может у меня на моей колокольни глаз замылен и я вижу все не так как следует, но по-моему, я описал как раз те вопросы которые должны возникнуть у потенциальных разработчиков. Я, как раз, отталкивался от вопросов которые мне уже задавали (в том числе на https://gitter.im/rsdn/nemerle).
K>Нет, речь не о том и не в такой форме. Мы говорим об "абстрактном" компиляторе, который вынужден проходить какие-то стадии и что-то делать. У тебя это расписано. Но для них (остального мира) мы должны объяснить наглядно, разжёвывая каждую стадию и поясняя, что за нас уже сделано самой Нитрой (или планируется). Milestone — это уже конкретные этапы конкретного продукта, кратко расписанные для удобочитаемости.
Честно говоря все равно не понял в чем разница. Milestone — это и есть разжевывание.
K>Кратко, вот в том списке стадий компиляции нужно пометить жирным, что Нитра должна делать за нас (всё, и сделанное, и планируемое),
Нитра — это инструмент. Она за нас ничего не делает. Она предоставляет средства реализации. Ну, как C# или C++. Чтобы понять, что она предоставляет лучше прочесть статьи по ней. К сожалению они тоже все на русском и ты сам тут рядом предъявлял к ним претензии. Возможно поможет чтение Реализация языка программирования Mini C на Nitra
Автор: VladD2
Дата: 12.01.17
.Дата: 12.01.17
K>а уже эти жирные части раскрасить синим — сделанные, красным — планируемые. Если какая-то фича — сложная и сделанная наполовину, не грех её разбить на пару предложений и выделить не сделанное.
Говорить о сделано / не сделано можно только в рамках проектов. Вот в проекте Cx# (он же CSharp.Grammar) коне что сделано. И я описал что. Можно по подробнее расписать этот и другие проекты. Но боюсь, что здесь детализация тоже же будет размывать картину.
K>Вот тогда один взгляд на список сразу даст понимание состояния проекта. Да, альтернативы туда тоже нужно внести, может даже блок-схемой: разные бэкенды, разные платформы и т.п.
Честно говоря, по-моему, для того чтобы дело начало двигаться важно не понимание состояния проекта, а чтобы люди начали мне помогать. Другими словами, чтобы люди из созерцателей превратились в помошников — комьюнити развивающее язык.
Я уже несколько раз закидывал идею начала работы над языками, но все хлапали глазки и даже не вступали в дискуссию. А когда дискуссия спонтанно завязалась на https://gitter.im/rsdn/nemerle, быстро выяснилось, что она перешла в обсуждение где найти по больше фич, которые желательно впихнуть в язык. Вот только я и сам знаю что можно впихнуть я язык. А проблема не в этом, а в том, чтобы начать этот язык равивать.
Даже скажу больше. Проблема в том, чтобы люди начали знакомиться с самой Нитрой. В процессе я как-нибудь объяснил бы детали. И план я тоже могу составить. Это не проблема.
За все время откликнулся только один человек Василий Кириченко. Он даже сделал тот самый пример Mini-C на котором я убедился, что человек со стороны вполне может освоить Нитру. Но потом он тихо исчез. Было еще 2-3 человека которые дальше разговоров не пошли.
Подозревают, что есть какие-то технические и/или психологические аспекты препятствующие активном включению в проект. Но, к сожалнеию нет даже простого фитбэка. Так что я даже не могу выявить эти поблемы.
K>Ну вот, список стадий уже есть! Ты даже написал про уже сделанные модули, но они нужны в самом списке, а не подстрочником.
Я не понимаю, что такое подстрочник. Включать их в сам список — это значит еще больше его раздувать. По-моему, все и так довольно очевидно. В Cx# сделано все до типизации тел методов. Но многое из сделанного еще нужно допиливать напильником (нужна куча дополнительных проверок соответствии спецификации). А не сделаны типизация тел и кодогенерация и сериализация сборок на диск.
K>Вопрос не в тему: про объединении C+#x$% и Nemerle-2 ты упомянул, что "АСТ можно вынести в общий модуль" — это как и зачем??
Ну, вот как-бы об этом я и писал. Вся первая часть этому и была посвящена. Но ты сказал, что это не важные детали, а выходит, что то ли не прочел, то ли не понял.
K>АСТ — это же структура в памяти,
Ну и что что в памяти? У тебя объект — это тоже "структуры в памяти", но чтобы они были тебе же нужно описать классы? Вот и в АСТ нужно описать типы АСТ на освновании которых будут уже структуры в памяти создаваться (в рантайме). Все правила типизации описываются на этих структурах (т.е. на АСТ). И об этом я тоже сказал.
K>причём у каждого языка — своя (несмотря на подавляющую схожесть).
Опять таки и об этом я скзал. 80% таких структур будет одинаковыми (идентичными). Нет смысл описывать их для каждого языка. Уникальные вещи воде паттерн-матчинга — надо. Но кроме них есть еще куча общих вещей. На то он и AST. Первая буква в слове "AST" помнишь, что означает? Это — Abstract. На то он и абстракный, чтобы не зависит от конкретного языка.
K>Рантаймовую структуру вынести в модуль??
У тебя явно путанница между стадиями. АСТ — это рантайм структура компилятора, а не самого языка. Вот текст на языке разбирается и переводится (в памяти компилятора) в АСТ. На АСТ-е прозводятся вычисления и по аннотированному АСТ просзводится уже генерация кода (это упрощенно).
Я описал, что есть проект DotNetLang в котором и собран общий для всех языков АСТ. Уникальный АСТ будет в проектах конкретных языков. Но его будет не много.