ВВ>Ты бы лучше объяснил нам, ламерам, как ты все это себе представляешь.. И на чем писать? На С++ или что по-круче?
Итак. Сначала о средствах разработки...
В качестве языка программирования для этой разработки я однозначно выбираю C#. На нем намного проще писать. Он порождает относительно шустрый код. Он позволяет избежать многомесячной отладки. Модель кода (о ней чуть позже) просто идеально подходит для GC (не нужно следить за ссылками и освобождать их). Ну, и в конце концов конечную версию компилятора можно будет скомпилировать на самом же новом компиляторе.
В проект будет включен только компилятор в MSIL, т.е. генерация кода для конкретного процессора, оптимизация и множество других низкоуровневых проблем.
1.1. Как первый подэтап нужно создать парсер C# 2.0 который будет читать исходные файлы C# и воздавать дерево разбора (объектную модель схожую с CodeDom, но более полную и удобную). Назавем это RsdnCodeModel.
1.2. Второй подэтап — нужно создать генератор кода. На вход ему будет подаваться дерево RsdnCodeModel, а на входе получаться MSIL (сборки).
2. Второй этап как раз продумывание и добавление нужных фич. (до этого еще нужно дожить).
В качестве теории всем кто хочет принять участие в данном проекте нужно будет изучить литературу по теории построении компиляторов. Например, вот эту книгу: Компиляторы: принципы, технологии и инструментарий. Так же можно просто поискать по книжным сайтам по слову компиляторов.
Теперь по подробнее... Разберем п. 1.1.
Писать парсер вручную очень и очень
Для создания парсеров используются клоны знаменитейшей программы yacc (переводится как еще один компилятор компиляторов). Я провел некоторые исследования и вывил два лучше всего подходящих для этого проекта клона:
1. Порт на .NET довольно известного клона yacc-а — Jey-я. Данный порт сделан разработчиками моно (http://go-mono.org). Имеется кривенькая (не соответствует стандарту) но все же рабочая реализация компилятора.
2. ANTLR (http://www.antlr.org) нечто самостийное. Честно говоря не разбирался (увлекся ждеем). Но многие хвалят. Говорят круто. Как я понимаю эта штука поддерживает шаблоны (впрочем как и Jey) что позволяет генерировать на нем в том числе и исходники на C#-е.
Преимущества Jey-я:
1. Написан на С (быстро работает, в качестве runtime-а нужна одна DLL-ка).
2. Парсер генерируется по шаблоне, который легко меняется (просто файл).
3. Для него есть две грамматики. Одна из них просто из проекта Моно (т.е. хотя и кривая, но проверенно рабочая). Другая из книжки которую я привел выше.
4. Я с ним вроде как разобрался.
5. Классический yacc (много документации).
Недостатки Jey-я:
1. Похоже что он менее гибок по сравнению с ANTLR.
2. Генерируемый код тяжело поддается отладке.
3. Довольно тяжело обеспечить качественную обработку ошибок возникающих при прасинге.
О ANTLR-е... (Честно говоря я мало о нем знаю, но все же)
Достоинства ANTLR-а:
1. Генерирует читабельный код разбора (использует LL(k) грамматику — т.е. последовательный разбор хорошо укладывающийся в голову людей).
2. Вроде как гибок и крут, но так как я в нем ничерта не понимаю все это слова авторов...
Недостатки ANTLR-а:
1. Использует Яву 1.1. (собственно на ней написан).
2. Я его почти не знаю.
3. Имеющаяся грамматика для C# явно не соответствует стандарту.
4. Нет реальных реализаций компиляторов C# сделанных на ANTLR.
5. Судя по всему он медленнее чем Jey, но это не главное. Главное насколько быстр получаемый парсер. В Jey-е вроде как получается ДКА (детерминированный конечный автомат), т.е. шустрее уже некуда. С другой стороны может и ANTLR тоже генерит приличный код.
На счет копирайтов не разбирался. Но похоже сгенерированный код на обоих можно использовать без каких бы то ни было отчислений.
PS
Задачи на ближайшее будующее
1. Определиться в выборе генератора парсера.
У меня уже есть лексер совместимый с Jey-ем. ANTLR сам имеет в себе средства лексического разбора.
2. Взять за основу имеющуюся грамматику и создать на ее основе дерево разбора. В принципе на Jey-е у меня уже есть кое какие наработки. Могу выложить на сайт.
Если выберем Jey, то в принципе можно воспользоваться Моновскими наработками. У них уже есть готовый компилятор. Проблема только в копирайтах. Кому ни будь нужно провентилировать вопрос "насколько можно использовать код Моно" в такой разработке. Если можно. То задача упрощается до нельзя. Правда там есть некоторые кривости которые следовало бы исправить. Ну, да это куда проще, чем делать свой компилятор с нуля.
Самой большой проблемой в Моно является то, что их генератор кода намертво сросся с парсером. А парсер было бы очень полезно иметь отдельно, так как его можно использовать для разбора кода (например, для конвертации C# в VB).
... << RSDN@Home 1.1.2 beta 1 >>
16.12.03 19:18: Перенесено модератором из '.NET' — TK
18.12.03 06:12: Перенесено модератором из 'Философия программирования' — IT
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Мое видение того как можно разработать новый язык для до
Hello, "VladD2"
> В качестве теории всем кто хочет принять участие в данном проекте нужно будет изучить литературу по теории построении компиляторов. Например, вот эту книгу: Компиляторы: принципы, технологии и инструментарий. Так же можно просто поискать по книжным сайтам по слову компиляторов. >
Здравствуйте, VladD2,
Написал не один транслятор, могу точно сказать, что это займет кучу человеко часов
(например трансляция параллельного паскаля в с++ с побайтной совместимостью структур данных для одной нерусской компании озадачила 4х человек на период 8 месяцев).
С компилятором всё будет еще безрадостнее ведь написать фронтенд — это 5% дела, если не меньше, качественный бакэнд и оптимизация, построение (пусть даже в некоторой степени автоматизированное) _кучи_ тестов и выяснение того, что реализация удовлетворяет языковой спецификации однажды заставят вас взвыть
Разработку подобного софта могут позволить себе обеспеченные люди.
Re: Мое видение того как можно разработать новый язык для до
> В качестве языка программирования для этой разработки я однозначно выбираю C#. На нем намного проще писать. Он порождает относительно шустрый код. Он позволяет избежать многомесячной отладки. Модель кода (о ней чуть позже) просто идеально подходит для GC (не нужно следить за ссылками и освобождать их). Ну, и в конце концов конечную версию компилятора можно будет скомпилировать на самом же новом компиляторе.
Тогда уж логичнее было бы писать на МС++, а наиболее критические места на обычных сях. Все же компилятор на С# — это довольно круто.. Да и потом, тебе на работе C# еще не надоел?
Posted via RSDN NNTP Server 1.8 beta
Re: Мое видение того как можно разработать новый язык для до
ВВ>>Ты бы лучше объяснил нам, ламерам, как ты все это себе представляешь.. И на чем писать? На С++ или что по-круче?
VD>Итак. Сначала о средствах разработки...
[skipped...]
зачем огород городить... с# парсер есть в сорсах от макрософта — sscli (поищите на сайте ссылка где-то была)
его мона взять от туда как базис...
плюсы этого дела:
— аля стандарт от макрософт
— точно не напоримся на грабли с парсером (макрософты уже почти все сделали)
— парсер написан на с++ — так-что шустрый и объектный
— есть набор начальных тестов для парсера
минусы:
— лицензия на использование (но мне лично пофиг)
— на сколько я понял там стандарт 1.0 только
— комерческого успеха не будет... и как доказать кастомеру что язык на котором я напишу круче с#???
— то что это развлечение для "богатых" духом и деньгами — это точно... даже банальный парсер XML или HTML занимает почти месяц полных усилий... по-этому на момент выхода первой rsdn версии компайлера, он может очень сильно потерять актуальность...
но я бы подписался на это только ради множественного наследования... и шаблонов...
щас пишу проект — достает это копирование функционала или писание оберток на готовую реализацию. стрелять хочеться и приведение типов иногда достает...
Re: Мое видение того как можно разработать новый язык для до
1) Написание полноценного компилятора это очень трудоемкая задача
2) Не смотря на JIT дотнетные компиляторы все таки оптимизируют
3) Несовместимость со стандартными компиляторами
4) Невозможность угнаться за МС. Новые фичи в свой язык будут добавляться позже чем с шарп.
Мне кажется более верным написание продвинутого препроцессора, способного обрабатывать исходники не как просто текст, а с учетом его синтаксической структуры, т.е. эдакий гибрид плюсовых шаблонов и обычного макропроцессора.
Здравствуйте, <Аноним>, Вы писали:
А>Здравствуйте, VladD2, А>Написал не один транслятор, могу точно сказать, что это займет кучу человеко часов А>(например трансляция параллельного паскаля в с++ с побайтной совместимостью структур данных для одной нерусской компании озадачила 4х человек на период 8 месяцев). А>С компилятором всё будет еще безрадостнее ведь написать фронтенд — это 5% дела, если не меньше, качественный бакэнд и оптимизация, построение (пусть даже в некоторой степени автоматизированное) _кучи_ тестов и выяснение того, что реализация удовлетворяет языковой спецификации однажды заставят вас взвыть
А>Разработку подобного софта могут позволить себе обеспеченные люди.
Ну не знаю. Я вот написал парсер C# 1.0 два года назад.
Он загонял инфу в расширеный CodeDom,
если кто не знает от его классов можно наследоваться и также перекрывать методы генерации у класса CSharpCodeGenerator.
Все это у меня студента без опыта (только теория) заняла 2 месяца.
А вот поповоду Compiler Compilers мне больше всего понутру JavaCC ( LL(k) — свой синтаксис), его вроде бы
даже Oracle используют. Я его как раз на C# переписываю с генерацией кода, и потом думал еще парсеров написать для .NET,
но времени мало, работа затягивает
... << RSDN@Home 1.1.0 stable Nautilus Pompilius — Во время дождя>>
Re[5]: Мое видение того как можно разработать новый язык для
Здравствуйте, V.Petrovski, Вы писали:
VP>Он загонял инфу в расширеный CodeDom, VP>если кто не знает от его классов можно наследоваться и также перекрывать методы генерации у класса CSharpCodeGenerator.
VP>Все это у меня студента без опыта (только теория) заняла 2 месяца.
VP>А вот поповоду Compiler Compilers мне больше всего понутру JavaCC ( LL(k) — свой синтаксис), его вроде бы VP>даже Oracle используют. Я его как раз на C# переписываю с генерацией кода, и потом думал еще парсеров написать для .NET, VP>но времени мало, работа затягивает
Ну, так может сообще что-нить полезное замутим?
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Мое видение того как можно разработать новый язык для
Здравствуйте, <Аноним>, Вы писали:
А>Написал не один транслятор, могу точно сказать, что это займет кучу человеко часов
А мы никуда не торопимся. Присоеденяйся! Хот опытом поможешь.
А>С компилятором всё будет еще безрадостнее ведь написать фронтенд — это 5% дела, если не меньше, качественный бакэнд и оптимизация, построение (пусть даже в некоторой степени автоматизированное) _кучи_ тестов и выяснение того, что реализация удовлетворяет языковой спецификации однажды заставят вас взвыть
А я и предлогаю делать только фронтэнд. Ведь компиляция делается в МСИЛ. А оптимизацией занимается Jit. Конечно некоторую оптимизацию можно и в компилятор встроить. Но это уже фигня по сравнению с теми оптимизациями, что делаются в Jit-компиляторе дотнета.
Тестами же будут реальные проекты: Хоум, сам компилятор, Моно, Ротор...
А>Разработку подобного софта могут позволить себе обеспеченные люди.
Кто тебе сказал, что мы тут бедные?
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Мое видение того как можно разработать новый язык для
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Тогда уж логичнее было бы писать на МС++, а наиболее критические места на обычных сях. Все же компилятор на С# — это довольно круто..
Ничего логичного я тут не вижу. Нет там никаких таких "критических мест". Скорости Шарпа более чем достаточно. Тот же Моновский компилятор написан именно на Шарпе и никаких проблем нет.
ВВ>Да и потом, тебе на работе C# еще не надоел?
Да нет пока. С++ надаел куда больше.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Мое видение того как можно разработать новый язык для
Здравствуйте, alku, Вы писали:
A>зачем огород городить... с# парсер есть в сорсах от макрософта — sscli (поищите на сайте ссылка где-то была) A>его мона взять от туда как базис...
1. SS CLI поставляется под драконовской лицензией.
2. Он написан на С++ и очень сложен в изучении, доработке, поддержке.
3. Его практически нельзя выделить в отдельный компонент. А сам по себе парсер очень даже не помешал бы.
A>плюсы этого дела: A>- аля стандарт от макрософт
Э... А чем так то будет не стандарт?
A>- точно не напоримся на грабли с парсером (макрософты уже почти все сделали)
Да они все сделали. Но нам то нужна хорошая расширяемость и устойчивость к ошибкам. Проект то открытый. А именно тут тот дремучий С++-ный код как раз будет мешать.
A>- парсер написан на с++ — так-что шустрый и объектный
Моновский написан на Шарпе и тоже шустрый и еще более объектный. A>- есть набор начальных тестов для парсера
Э... Дык тесты то они и в Африке будут тестами.
A>минусы: A>- лицензия на использование (но мне лично пофиг)
А мне нет. Я хочу иметь полное право создавать коммерческие проекты на его основе.
A>- на сколько я понял там стандарт 1.0 только
Нет. Есть обновления. Даже дженерики доступны. Но вот 2.0 не поддерживается. Хотя к выходу скорее всего они его обновят.
A>- комерческого успеха не будет... и как доказать кастомеру что язык на котором я напишу круче с#???
Сне успех не нужен. Мне нужен увлекательный проект с полезным результатом.
A>- то что это развлечение для "богатых" духом и деньгами — это точно...
Так мы что бедные тут все?
A> даже банальный парсер XML или HTML занимает почти месяц полных усилий... по-этому на момент выхода первой rsdn версии компайлера, он может очень сильно потерять актуальность...
Вряд ли. Как минимум не нужно будет ждать милости от приро... МС.
A>но я бы подписался на это только ради множественного наследования... и шаблонов...
Э... Зачем тебе МН? Вместо него предлагается сделать подключение реализации.
Шаблоны же вообще детство по сравнению с тем, что я предлагаю добавить. Я предлагаю добавить полноуенный энжин для метапрограммирования. Это то для чего в последнее время пытаются приспособить С++-шаблоны. Причем результат плучается уродливым.
Я предлагаю сделать не просто шаблоны. А удобное и безкомпромисное средство для решения тех же задач по лдюски.
A>щас пишу проект — достает это копирование функционала или писание оберток на готовую реализацию. стрелять хочеться и приведение типов иногда достает...
Приведение типов лечится дженериками которые уже на подходе. С подключением функциональности все сложнее. Вот я и предлагаю первым пунктом добавить это: А не залудить ли нам свой язык для дотнета?
Здравствуйте, Дмитрий Наумов, Вы писали:
ДН>Перед тем как разбираться что делать и как делать хотелось бы услышать а зачем? Какие цели необходимо достигнуть?
Здравствуйте, AndrewVK, Вы писали:
AVK>1) Написание полноценного компилятора это очень трудоемкая задача
Думаешь я не догадываюсь?
AVK>2) Не смотря на JIT дотнетные компиляторы все таки оптимизируют
Вот только тлку от этого нет. Да и оптимизации там детские. Их можно и сделать.
AVK>3) Несовместимость со стандартными компиляторами
Откуда? Обратная совместимость одна из задач проекта.
AVK>4) Невозможность угнаться за МС. Новые фичи в свой язык будут добавляться позже чем с шарп.
Гы. Вот тут вообще фигня. Новые фичи мы уж точно будем вставлять быстрее МС. А те что делает МС тоже будет добавлять как только о них будет появляться информация.
AVK>Мне кажется более верным написание продвинутого препроцессора, способного обрабатывать исходники не как просто текст, а с учетом его синтаксической структуры, т.е. эдакий гибрид плюсовых шаблонов и обычного макропроцессора.
Гы. Ты вдумайся в свои слова. Это означает создать полноценный парсер. А ето 80% компилятора.
Я тоже думал о препроцессоре. Но пришел к выводу, что все же это полумера. Препроцессор же с синтаксическим анализом это почти то о чем я и гворю. Просто собственный генератор МСИЛ-а даст еще больше гибкости.
В любом случае я хочу не сделать те ошибки, что были сделаны МС и Моно — мертвое сращивание парсера и компилятора. Я хочу создать компилятор на базе отдельного компонента парсер. Чтобы парсер можно было бы исполььзовать для сериализации форм, отображения структуры кода, рефакторинга и т.п.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Мое видение того как можно разработать новый язык для
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, V.Petrovski, Вы писали:
VP>>Он загонял инфу в расширеный CodeDom, VP>>если кто не знает от его классов можно наследоваться и также перекрывать методы генерации у класса CSharpCodeGenerator.
VP>>Все это у меня студента без опыта (только теория) заняла 2 месяца.
VP>>А вот поповоду Compiler Compilers мне больше всего понутру JavaCC ( LL(k) — свой синтаксис), его вроде бы VP>>даже Oracle используют. Я его как раз на C# переписываю с генерацией кода, и потом думал еще парсеров написать для .NET, VP>>но времени мало, работа затягивает
VD>Ну, так может сообще что-нить полезное замутим?
Замутить то можно, но у меня со свободным временем напряги.
Ну чем могу помогу в свободное время.
Здравствуйте, VladD2, Вы писали:
AVK>>1) Написание полноценного компилятора это очень трудоемкая задача
VD>Думаешь я не догадываюсь?
Так может начать с малого — с написания парсера. Это куда менее трудоемко, а результат полезен не только в компиляторах.
AVK>>2) Не смотря на JIT дотнетные компиляторы все таки оптимизируют
VD>Вот только тлку от этого нет. Да и оптимизации там детские. Их можно и сделать.
ЧТо то меня подобная перспектива пугает. В янусе вон куда более простые вещи бывает месяцами реализовать не можем, а здесь оптимизатор.
AVK>>3) Несовместимость со стандартными компиляторами
VD>Откуда? Обратная совместимость одна из задач проекта.
Прямой нет. Если вдруг по каким то причинам мне понадобится отказаться от компилятора на существующем проекте в пользу стандартного, сделать мне это будет очень сложно. Это плюс для коммерческого проекта и минус для некоммерческого.
AVK>>4) Невозможность угнаться за МС. Новые фичи в свой язык будут добавляться позже чем с шарп.
VD>Гы. Вот тут вообще фигня. Новые фичи мы уж точно будем вставлять быстрее МС.
Не уверен. Наверное все же программеры в МС не зря свой хлеб едят. Команда, разрабатывающая шарп как минимум не меньше той что у нас и не хуже квалификацией. Почему у нас будет получаться лучше?
AVK>>Мне кажется более верным написание продвинутого препроцессора, способного обрабатывать исходники не как просто текст, а с учетом его синтаксической структуры, т.е. эдакий гибрид плюсовых шаблонов и обычного макропроцессора.
VD>Гы. Ты вдумайся в свои слова. Это означает создать полноценный парсер.
Именно
VD>А ето 80% компилятора.
Нет конечно. Самым сложным всю жизнь был семантический, а не синтаксический анализатор.
VD>Я тоже думал о препроцессоре. Но пришел к выводу, что все же это полумера. Препроцессор же с синтаксическим анализом это почти то о чем я и гворю. Просто собственный генератор МСИЛ-а даст еще больше гибкости.
Но при этом привнесет и вышеперечисленные недостатки. Честно говоря больше всего меня пугают 3 и 4 пункт. Настолько пугают что я готов обойтись без предполагаемых фич. И еще меня пугает попытки добавить что то уже сейчас даже не подумав о последствиях. Ну вроде вызова методов дедушки через голову родителя.
Здравствуйте, AndrewVK, Вы писали:
VD>>Гы. Ты вдумайся в свои слова. Это означает создать полноценный парсер.
AVK>Именно
VD>>А ето 80% компилятора.
AVK>Нет конечно. Самым сложным всю жизнь был семантический, а не синтаксический анализатор.
Может реализовать предикаты подходящим образом в имеющемся шарпе. Тогда обе эти задачи могут упроститься. И с этим арсеналом двинутся дальше. Достоинства: опыт в подобном вопросе + все свое. Один из путей реализации это препроцессор, который будет разворачивать тела в обычный шарповский код.
Re[3]: Мое видение того как можно разработать новый язык для
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, alku, Вы писали:
A>>зачем огород городить... с# парсер есть в сорсах от макрософта — sscli (поищите на сайте ссылка где-то была) A>>его мона взять от туда как базис...
[skipped...]
все это гут, но хочеться пока бональных вещей которых нет в С#, но есть в с++...
препроцессор + шаблоны + множественное наследование (по сути согласен и на подключении реализации)
generic это хорошо, но пока мне лично не доступно (взять негде), вот и приходиться выкручиваться текстовыми шаблонами кода... а три вещи сверху свели бы мой труд на написание пары строк кода и получения готовой и протестированной реализации...
демагогоия
конечно ни кто не мешает нам написать rsdn язык на с#, но зачем? это не даст нам ничего хорошого...
сам по себе парсер не юзает никаких серьезных навороов с#, там простой токенайзер -> лексемы -> дерево лексем...
а быстрее от с# парсер не станет, возможно наоборт приобретет местами объектную неповоротливость...
взять за пример привидение типов: с# потратит на это намного больше процессорного времени чем с++... а нам нужен компайлер который по пол года работать будет? сомневаюсь... нормальный проект легко перепрыгивает планку 100'000 строк и 10 под проектов в сольюшене... и время компиляции критично... ради запуска на дебаг пол года ждать не хочу...
может это конечно показаться немного "легковесными" аргументами, но мона подыскать и другие... не спорю что с# даст большую надежность (сомнительно), но со скоростью я не согласен... что бы там не писали про скорость с# — он должен уступать ей по сравнению с с++ (а все остальное что публикуються как новшества в основном давно известный стратегии повышение стабильности и скорости работы разработанные под с++).
еще один аргумент: с++ — намного легче щас перевести под другие платформы... на основе парсера мона будет создать что-то на подобии Visual Assist'a... а это в основном как раз, то чего не хватает...
если написать на с# то это начнет напоминать студенческую разработку... что-то на пример XSLT пре-процессора выпущенного для разработчика реализаций... был написан на Java и ничего кроме как правильно, но очень медленно делать не умел... так сказать эталон был по правильности, но не по скорости...
и разработка комилятора/парсера должно быть дело для профи... а профи все на с++ пишут (шутка)
Re[7]: Мое видение того как можно разработать новый язык для
На нем намного проще писать. Он порождает относительно шустрый код. Он позволяет избежать многомесячной отладки. Модель кода (о ней чуть позже) просто идеально подходит для GC (не нужно следить за ссылками и освобождать их). Ну, и в конце концов конечную версию компилятора можно будет скомпилировать на самом же новом компиляторе.
Как я понимаю эта штука поддерживает шаблоны (впрочем как и Jey) что позволяет генерировать на нем в том числе и исходники на C#-е.
