ВВ>Ты бы лучше объяснил нам, ламерам, как ты все это себе представляешь.. И на чем писать? На С++ или что по-круче?
Итак. Сначала о средствах разработки...
В качестве языка программирования для этой разработки я однозначно выбираю 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]: Мое видение того как можно разработать новый язык для
Здравствуйте, alku, Вы писали:
A>все это гут, но хочеться пока бональных вещей которых нет в С#, но есть в с++... A>препроцессор + шаблоны + множественное наследование (по сути согласен и на подключении реализации)
Система метапрограммирования о которой я говорю будет замещать препроцессор + шаблоны на 100%. Причем будет намного гибче и круче.
A>generic это хорошо,
Все равно работающий проект до выхода Видби не получится. Так что можно считать, что за generic-ками гнаться не стоит.
A>демагогоия A>конечно ни кто не мешает нам написать rsdn язык на с#, но зачем? это не даст нам ничего хорошого...
Ошибаешся.
A>сам по себе парсер не юзает никаких серьезных навороов с#, там простой токенайзер -> лексемы -> дерево лексем...
Так деревья на GC ложатся просто изумительно! А простота Шарпа позволит существнно снизить сложность проекта.
A>а быстрее от с# парсер не станет, возможно наоборт приобретет местами объектную неповоротливость...
Быстрее не станет. Но и медленнее или хуже тоже. Зато станет значительно проще. Моновский парсер читать на порядки проще чем МС-ный.
A>взять за пример привидение типов: с# потратит на это намного больше процессорного времени чем с++...
Да не намного. Зато гарантирует, что все ОК. А на плючах на одной отладке будешь черти сколько времени тратить. К тому же квалификация участников проекта потребуется значительно выше. А это отпугнет народ.
A> а нам нужен компайлер который по пол года работать будет?
Скачай Моно — убедись, что он не медленнее МС-ного компилирует.
A>не спорю что с# даст большую надежность
Вот именно! И простоту!
A> (сомнительно)
Не сомневайся. Уже есть пример в лице Моно.
A>, но со скоростью я не согласен...
Зря. Это предрассудок.
A>еще один аргумент: с++ — намного легче щас перевести под другие платформы...
Без рантайма первеводить дотнет нет смысла. Да и вообще нет смысла. Так что где будет тот же Моно и мы будем. А где нет, там и не надо.
A> на основе парсера мона будет создать что-то на подобии Visual Assist'a... а это в основном как раз, то чего не хватает...
Ну, по сравнению с Видби визаул-ассист просто детский лепет. Я уже перестал им пользоваться. А парсер как раз и будет доступен если он будет менеджед.
A>если написать на с# то это начнет напоминать студенческую разработку...
Предрассутки! Уверяю тебя.
A>и разработка комилятора/парсера должно быть дело для профи... а профи все на с++ пишут (шутка)
Профи уже давно ползут с С++
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Мое видение того как можно разработать новый язык для
Здравствуйте, VladD2, Вы писали:
VP>>Замутить то можно, но у меня со свободным временем напряги. VP>>Ну чем могу помогу в свободное время.
VD>Если бы ты знал насколько хренова со временем у меня. VD>Но все же хочется заняться чем-то для души.
А вот и правда — ты прикинь примерно сроки, которые на это понадобятся. Может просто препроцессинг нормальный прикрутить?
1. Компилятор строется как ядро позволяющее поключать плагины. Это позволит добавлять ресерчные фичи не меняя основного проекта. И позволит сздавать конкурирующие реализации идей. Примерное видение:
2. Вставки на МСИЛ-е. Это позволит делать различные оптимизации, так же как это было возможно на С++ или Дельфи. Вставляем в код секцию __msil и получаем доступ к телу.
Здравствуйте, AndrewVK, Вы писали:
AVK>Так может начать с малого — с написания парсера. Это куда менее трудоемко, а результат полезен не только в компиляторах.
Собственно именно так я и планирую сделать. Если внимательно прочесть мой план, то можно заметить, что парсер стоит первой задачей.
AVK>ЧТо то меня подобная перспектива пугает. В янусе вон куда более простые вещи бывает месяцами реализовать не можем, а здесь оптимизатор.
Еще раз. Джит делает львиную долю оптимизаций. Именно по этому я и говорю о компиляции в мсил и даже не обсуждаю вариант с полноценным компиляторов в машинный код.
Ну, и именно поэтому я хочу сделать открытый проект. Это даст возможность работать параллельно.
Кстати, классно было бы сделать компилятор с плагинами (вроде идея Ведмедя). Тогда бы доработка упростилась бы до нельзя. А для этого нужно просто все делать в компонентном стиле. И помнить о плагинах. По сути парсер будет некой компонентной моделью позволяющей программно анализировать и изменять дерево разбора. Потом найдется орел который напишит "плагин-оптимизатор того то", а еще чуть погодя "плагин-оптимизатор сего-то"... Глядишь так мы вообще в законодатили компиляторной мысли выйдем, и Москву переименуют в Олд РСДН.
AVK>Прямой нет.
А зачем она? Мы сможем компилировть любой исходник. Как свой, так и Шарповый. Что еще надо?
AVK> Если вдруг по каким то причинам мне понадобится отказаться от компилятора на существующем проекте в пользу стандартного, сделать мне это будет очень сложно. Это плюс для коммерческого проекта и минус для некоммерческого.
Не, ну, это уже из области фантастики. В любом случае можно всегда заморозить развитие сборки созданной на ресерчном компиляторе, отнаследоваться и развивать класс на обычном компиляторе. Ведь по сборкам мы будет полностью совместмы.
VD>>Гы. Вот тут вообще фигня. Новые фичи мы уж точно будем вставлять быстрее МС.
AVK>Не уверен. Наверное все же программеры в МС не зря свой хлеб едят.
Они остарожничают. А у нас ресерчный язык. Так что нет администратевного гнета. Если сделать все на плагинах, так вообще добавление новых фич будет довольно простым занятием.
AVK>Команда, разрабатывающая шарп как минимум не меньше той что у нас и не хуже квалификацией. Почему у нас будет получаться лучше?
Что касаемо квалификации, то да. А по размеру... Все зависит от народа и задора. Хотя не в размере счастье.
VD>>А ето 80% компилятора.
AVK>Нет конечно. Самым сложным всю жизнь был семантический, а не синтаксический анализатор.
Ошибаешся. 80% ошибкок и тракха именно синтаксис. К тому, же полноценный парсер просто обязан поддерижвать семантический анализ. Так как иначе во многих случаях вообще нельзя квалифицировать некоторые конструкции.
AVK>Но при этом привнесет и вышеперечисленные недостатки. Честно говоря больше всего меня пугают 3 и 4 пункт. Настолько пугают что я готов обойтись без предполагаемых фич.
Короче. Я так понимаю, что нам обоим нужен качественный не ограниченный лицензиями, и понятный нам парсер. Я прав? Значит уже есть над чем тудиться вместее. Предлагаю начать!
Вот только серьезно я этим смогу заняться после нового года. Веренее после сдачи РСДН-а №6. Так как иначе мы его завалим.
AVK>И еще меня пугает попытки добавить что то уже сейчас даже не подумав о последствиях. Ну вроде вызова методов дедушки через голову родителя.
Ну, это вообще не вопрос. Делать будем только после всестороннего обсасывания. И делать будем на базе плагинной технологии. Чтобы можно было послать тех кто хочет "именно эту фичу"... делать плагин.
Так что нужно корошенько продумать вопрос о плагинизации.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Кстати, классно было бы сделать компилятор с плагинами (вроде идея Ведмедя). Тогда бы доработка упростилась бы до нельзя.
Не знаю. Все таки идея компилятора меня не увлекает. А с плагинами особенно, поскольку породит море несовместимых исходников.
AVK>>Прямой нет.
VD>А зачем она?
См. ниже
AVK>> Если вдруг по каким то причинам мне понадобится отказаться от компилятора на существующем проекте в пользу стандартного, сделать мне это будет очень сложно. Это плюс для коммерческого проекта и минус для некоммерческого.
VD>Не, ну, это уже из области фантастики.
Почему? Вот предположим начал я писать что то на самопальном компиляторе, потом от МС вышло то что мне больше понравилось/начальство заставило. С собственным компилятором у меня перейти просто не получится. Препроцессор кстати такой проблемы решен.
AVK>>Не уверен. Наверное все же программеры в МС не зря свой хлеб едят.
VD>Они остарожничают. А у нас ресерчный язык. Так что нет администратевного гнета.
Знаешь, они наверное все таки не зря осторожничают.
AVK>>Нет конечно. Самым сложным всю жизнь был семантический, а не синтаксический анализатор.
VD>Ошибаешся. 80% ошибкок и тракха именно синтаксис.
Не знаю, меня учили другому.
VD>К тому, же полноценный парсер просто обязан поддерижвать семантический анализ. Так как иначе во многих случаях вообще нельзя квалифицировать некоторые конструкции.
Здравствуйте, VladD2, Вы писали:
ВВ>>А вот и правда — ты прикинь примерно сроки, которые на это понадобятся. VD>Пол года-год.
Полгода спорадической работы по выходным?
ВВ>> Может просто препроцессинг нормальный прикрутить? VD>Мне это не интересно. Это полумера. Эдак я могу просто испоьзовать препроцессор от С++.
Ну на основе своего препроцессора можно и как-нибудь новые фички реализовать
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А вот и правда — ты прикинь примерно сроки, которые на это понадобятся. Может просто препроцессинг нормальный прикрутить?
Смотря на что. Пару-тройку Владо-дней на генерацию идей и ещё 3-4 человеко-года на их реализацию.
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: Мое видение того как можно разработать новый язык для
Здравствуйте, VladD2, Вы писали:
VD>Ну, по сравнению с Видби визаул-ассист просто детский лепет. Я уже перестал им пользоваться. А парсер как раз и будет доступен если он будет менеджед.
Подскажите плиз, что такое Видби и где его взять?
Спасибо.
Re[5]: Мое видение того как можно разработать новый язык для
A>>еще один аргумент: с++ — намного легче щас перевести под другие платформы...
VD>Без рантайма первеводить дотнет нет смысла. Да и вообще нет смысла. Так что где будет тот же Моно и мы будем. А где нет, там и не надо.
Вообще, по-моему, как только проект более-менее сформируется, имеет смысл законтачить с моновцами. Мало ли чего они там подбросят. Может, пропиарят немного на своём сайте.
Да и по-любому в Роторе тоже стоит засветиться. Как ни крути, а под ихнюю специфику проект попадает. Премию не премию, а всё-таки подружиться полезно. Можно консультироваться потом по специальным вопросам.
В любом случае престиж от таких засветок лично ждя участников проекта будет очень хороший. Дескать, я, там, Влад такой-то, мало того что большой босс в RSDN, но ещё и сотрудничаю с Mono и Microsoft SSCLI. У-у-у, сразу скажут потенциальные работодатели, платим тебе ещё штуку баксов.
... << RSDN@Home 1.1.0 stable >>
Re[8]: Мое видение того как можно разработать новый язык для
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, V.Petrovski, Вы писали:
VD>Кстати, ты каким образом парсер делал? Yacc-ом, еще чем, или вручную?
Это было в воремена beta 1 пришлось прикрутить тогда еще JCUP и JFlex для генерации C# кода.
Но чтобы этот парсер шустрым был лучше всего писать его рекурсивным с возможностью
заглядования на К символов. JavaCC позволяте писать парсер в таком виде
Здравствуйте, IT, Вы писали:
ВВ>>А вот и правда — ты прикинь примерно сроки, которые на это понадобятся. Может просто препроцессинг нормальный прикрутить?
IT>Смотря на что. Пару-тройку Владо-дней на генерацию идей и ещё 3-4 человеко-года на их реализацию.
А что такое Владо-день? Чем он отличается от Васе-дня?
Здравствуйте, VladD2, Вы писали:
VD>Две новые фичи в план...
VD>1. Компилятор строется как ядро позволяющее поключать плагины. Это позволит добавлять ресерчные фичи не меняя основного проекта. И позволит сздавать конкурирующие реализации идей. Примерное видение: VD>
Здравствуйте, AndrewVK, Вы писали:
AVK>Вот только не надо этих сишных префиксов
Не, тут ты не прав. Перфиксы это не сишные. Это способ создать конструкцию не конфликтующую с идентификаторами в приложениях. Дело в том, что ilasm или msil должны будут стать ключевыми словами. А это сразу приведет к тому, что код использующий их в качестве идентификаторов перестанет компилироваться и наш компилятор будет несовместим с Шарпом сверху вниз. Есть соглашение по которому двойное подчеркивание зарезервировано для компилятора и не может использоваться для обозначения идентификаторов. Именно по этому __ilasm или __msil.
Например, у МС есть недукументированное ключевое слово __arglist. Называно именно по этим соображениям.
Попробуй создать переменную:
int __arglist;
У нас просто нет другого выхода.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Мое видение того как можно разработать новый язык дл
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Полгода спорадической работы по выходным?
Так предпологается, что не одни человек будет работать. Темболее что кое-какие наработки уже есть. Да и не малый это срок.
ВВ>Ну на основе своего препроцессора можно и как-нибудь новые фички реализовать
Лучше уж реализовать свои фичи на основе нового языка.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Мое видение того как можно разработать новый язык дл
Здравствуйте, V.Petrovski, Вы писали:
VP>Но чтобы этот парсер шустрым был лучше всего писать его рекурсивным с возможностью VP>заглядования на К символов.
Погоди ка. Насколько я знаю яки создают ДКА, а ДКА — это самый эффективный алгоритм по распознованию. Или я не прав? А парсеры с заглядыванием обычно — это LL(k)-парсеры, ди и они обычно не в силах порождать ДКА. Я так понимаю у яков проблемы с простотой отладки (хотя тоже жить моно) и обработкой ошибок (но это уже вообще проблемы всех парсеров).
Проблема еще в том, что на яке есть нехилые наработки (почки готовая граматика и разбор в дерево половины этой граматики).
Что же касается
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Мое видение того как можно разработать новый язык для
Здравствуйте, AndrewVK, Вы писали:
VD>>К тому, же полноценный парсер просто обязан поддерижвать семантический анализ. Так как иначе во многих случаях вообще нельзя квалифицировать некоторые конструкции.
AVK>Например?
Да примеры тут и там. Например, приведение типов от выражения в скобках можно отделить или путем хакерских предположений, или просто проанализировав что находится в скобках.
Или в атрибутах могут быть как позиционные параметры, так и именованные. Но именованные обязаны быть последними. Сделать парсер учитывающий это очень не просто. Намного проще разобрать все параметры как выражения, а потом уже семантически проверить корректность.
В общем, есть куча мест где формальные парсеры не могут дать четкую классификацию выражения и делают по контексту
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Miem, Вы писали:
AVK>>Пока без комментариев, просто кусочек кода
M>Только не так! Пожалуйста! Вся прелесть такого читабельного языка как С# пропадает.
Предложи свой вариант. По мне так вполне читаьельно. Что конкретно тебя смущает?
Здравствуйте, Воронков Василий, Вы писали:
IT>>Смотря на что. Пару-тройку Владо-дней на генерацию идей и ещё 3-4 человеко-года на их реализацию.
ВВ>А что такое Владо-день? Чем он отличается от Васе-дня?
Намного менее очевидно. Кроме того совсем непонятно.
VD>Вот только это не так сложно и на жденириках сделать.
На дженериках можно этот конкретный пример еще лучше сделать. Не в этом суть.
VD>Второй вариант сделать по человечески сложнее. Тут уже ужно конкретно думать...
О! О том и речь. Если бы задача стояла делать типизированные коллекции то достаточно было бы шаблоноподобного синтаксиса. Но речь то не о создании механизма для типизированных коллекций, с этим и дженерики справляются, речь то о о куда более мощном механизме. И второй пример это самое простое что лично мне нужно. Могу тебе привести самый простой, но реальный пример генерации кода на xslt.
Вот и надо придумать способ записать тоже самое, но более внятным языком. В приведенном примере я постарался это сделать. Буду рад увидеть более читабельные варианты. Пример с атрибутами меня не воодушевил, а точнее совсем не понравился. Мешает все в одну кучу — непонятно где собственно код, а где его генерация, сразу сказать какой код получится в результате генерации крайне сложно.
VD>Основная проблема в том, что по этому коду нужно будет производить отладку. А тут уже чистая генерация кода.
По поводу компилятора я уже говорил — меня это не вдохновляет.
VD>ЗЫ
VD>Кстати, где взять Яву 1.1?
Зачем именно 1.1. Скачай 1.4.2. Брать разумеется на java.sun.com
Здравствуйте, VladD2, Вы писали:
AVK>>Вот только не надо этих сишных префиксов
VD>Не, тут ты не прав. Перфиксы это не сишные.
Тем не менее в шарпе такого нет и слава богу.
VD>Это способ создать конструкцию не конфликтующую с идентификаторами в приложениях.
Кривой, надо заметить способ. Я за добавление небольшого количества ключевых слов или реюз существующих. Меня всякие _printf __printf и прочая всегда в сях не нравились. ИМХО уродство это.
VD> Есть соглашение по которому двойное подчеркивание зарезервировано для компилятора и не может использоваться для обозначения идентификаторов. Именно по этому __ilasm или __msil.
А если я использую __ilasm — опять не совместимость? Инвалидное какое то, надо сказать решение. Уж давай тогда гуиды использовать?
ilasm4F4ED94F3E34483091ABF3F3229EF1E6
Как тебе? Такое точно вряд ли кто использует в качестве идентификатора
VD>Например, у МС есть недукументированное ключевое слово __arglist. Называно именно по этим соображениям.
Именно что недокументированное.
VD>Попробуй создать переменную: VD>
VD> int __arglist;
VD>
А ты попробуй создать getProp при наличии свойства Prop.
VD>У нас просто нет другого выхода.
Ну вот еще один довод почему не стоит писать свой компилятор
Здравствуйте, VladD2, Вы писали:
VD>Погоди ка. Насколько я знаю яки создают ДКА, а ДКА — это самый эффективный алгоритм по распознованию. Или я не прав?
В плане производительности? Да, прав.
VD> А парсеры с заглядыванием обычно — это LL(k)-парсеры,
Здравствуйте, AndrewVK, Вы писали:
AVK>Тем не менее в шарпе такого нет и слава богу.
Такие вещи используются когда нужно расширить язык и ну потерять обатной совместимости. В С++ такого тоже нет. Это делают те кто расширяет (нестандартно) компилятор и хочет добиться 100%-ой совместимости со стандартом.
AVK>Кривой, надо заметить способ. Я за добавление небольшого количества ключевых слов или реюз существующих.
Добавлять ключевые слова значит делать язык несовместимым с оригиналом, так как они могут использоваться в качестве идентификаторов.
AVK> Меня всякие _printf __printf и прочая всегда в сях не нравились. ИМХО уродство это.
Называть функции с двойным подчеркиванием вообще нельзя. Это могут себе позолить делать только разработчики компилятора.
Ну, а на счет эстетики... Ничего страшного. Другие способы еще кривее.
Если стоит выбор между эстетикой и совместимостью, то даже думать нечего.
AVK>А если я использую __ilasm — опять не совместимость?
Где используешь? В качестве названия идентификатора? Ну, это нарушение правил, и ответственность только на тебе. Вероятность такой дури равна нул.
AVK> Инвалидное какое то, надо сказать решение. Уж давай тогда гуиды использовать? AVK>ilasm4F4ED94F3E34483091ABF3F3229EF1E6 AVK>Как тебе? Такое точно вряд ли кто использует в качестве идентификатора
Ну, раз ты согласен...
VD>>Например, у МС есть недукументированное ключевое слово __arglist. Называно именно по этим соображениям.
AVK>Именно что недокументированное.
А наши что будут по отношению к языку документированны? __arglist назван именно так, чтобы не противоречить стандарту.
AVK>А ты попробуй создать getProp при наличии свойства Prop.
Ээээ... Наверно get_Prop? Ну, да это вроде оговорено. А наши ключевые слова по определению не оговорены.
VD>>У нас просто нет другого выхода.
AVK>Ну вот еще один довод почему не стоит писать свой компилятор
Это не довод.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>И что ты там птичьего увидел?
Грязь. Не код, а каша. О поддержке такой каши редактором даже и речи быть не может.
AVK>Намного менее очевидно. Кроме того совсем непонятно.
Все прекрасно понятно. Твой код тоже без коментариев непонятен. Зато читается легко и совместим с синтаксисом Шарпа. По сути меняется только семантика. Причем меняется она атрибутами.
AVK>О! О том и речь. Если бы задача стояла делать типизированные коллекции то достаточно было бы шаблоноподобного синтаксиса. Но речь то не о создании механизма для типизированных коллекций, с этим и дженерики справляются, речь то о о куда более мощном механизме. И второй пример это самое простое что лично мне нужно.
Понятно. Но кроме того, что "нужно", нужно еще учитывать и много других факторов:
1. Синтаксис должен быть максимально близок к Шарпу, чтобы работали редакторы и т.п.
2. Код должен легко читаться. Тут, кстати, тоже лучше быть похожим на Шарп, чтобы программисту не приходилось сильно переключаться.
AVK>Могу тебе привести самый простой, но реальный пример генерации кода на xslt...
Вот это уже вообще райт-онли.
Надо как-то наложить Шарп на Шарп. Т.е. чтобы метаязык был самим шарпом.
За одно такой подход позволит именно метопрограммировать, т.е. писать код пишущий код.
AVK>Вот и надо придумать способ записать тоже самое, но более внятным языком.
Согласен. Как тебе предложение о принятии синтаксиса Шарпа плюс хитрые атрибутц?
AVK> В приведенном примере я постарался это сделать. Буду рад увидеть более читабельные варианты.
К сожалению я не смог по большому счету прочесть это дело. Уситчивости не хватило.
Но, думаю, общей идее будут вложенные мета-вызовы. Т.е. вместо шаблона хслт выступает обычная функция. А вместо apply-templates некий атрибут выполняющий схожие действия.
AVK> Пример с атрибутами меня не воодушевил, а точнее совсем не понравился. Мешает все в одну кучу — непонятно где собственно код, а где его генерация, сразу сказать какой код получится в результате генерации крайне сложно.
Отчего же не понятно? Вопрос в том, что сами атрибуты — это уже применение. Генерация же должна быть в отдельных методах. И должна быть возможность повышения абстракции.
VD>>Основная проблема в том, что по этому коду нужно будет производить отладку. А тут уже чистая генерация кода.
AVK>По поводу компилятора я уже говорил — меня это не вдохновляет.
А что ты предлогаешь? Генерировать гигобайты кода и разбираться с ним? Ты даже не сможешь вынести каждый сгенерированный класс в отдельный файл, так как это уже связано со средой.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Просто даже M$ не чурается работать с университетами которые как раз выпускают будующих программистов компиляторов. Реально было бы посодрудничать с ними а заодно дать людям пищу для будущих диссертаций и научных изысканий. И помочь вырастить новое поколение программистов.
и солнце б утром не вставало, когда бы не было меня
Re[2]: Мое видение того как можно разработать новый язык для
Ты бы почитал, что там написано. Это упрошенный пример используемый для обучения детей в институтах. К ресерч-языку это отношения не имеет.
S> Просто даже M$ не чурается работать с университетами которые как раз выпускают будующих программистов компиляторов.
У нас почти все программисты этот курс проходят.
S> Реально было бы посодрудничать с ними а заодно дать людям пищу для будущих диссертаций и научных изысканий.
Я не против. Можно написать им писма и пригласить в проект.
S> И помочь вырастить новое поколение программистов.
Эээ... Пщай само растет. А то мы его скорее всего загубим.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Мое видение того как можно разработать новый язык для
VD>У нас почти все программисты этот курс проходят.
Во во курс проходят. Теория и практика две ооочень разные вещи. Сколько у тебя уйдет времени на вникание всех проблем. А у них есть уже наработки, свой парсер,
исходники. Но я абсолютно не говорю, что у них будет лучше чем у вас, но раз уж задумали такое дело то лучше привлечь практиков. При том, что они за это все равно хоть небольшую но денежку получают и могут потратить все Рабочее время, в отличии от некоторых.
Шутка.
и солнце б утром не вставало, когда бы не было меня
Re[2]: Мое видение того как можно разработать новый язык для
Здравствуйте, Serginio1, Вы писали:
S> Во во курс проходят. Теория и практика две ооочень разные вещи. Сколько у тебя уйдет времени на вникание всех проблем. А у них есть уже наработки, свой парсер, S>исходники. Но я абсолютно не говорю, что у них будет лучше чем у вас, но раз уж задумали такое дело то лучше привлечь практиков.
Да они скорее теоретики. Хотя, как я уже сказал, я только за.
S> При том, что они за это все равно хоть небольшую но денежку получают и могут потратить все Рабочее время, в отличии от некоторых. S> Шутка.
Ну, некоторые могут и все свободные ночи потратить.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Мое видение того как можно разработать новый язык для до
Твое видение того как можно разработать новый язык для дотнет -> А на кой ляд он нужен. какие в нем будут преимущества перед уже существующими. Для каких задач будет применятся. Или это просто милое упражнение по теории компиляторов после прочтения книжки Ахо. Не сочтите вышеприведенную фразу за оскорбление — не хотел вас обидеть, клянусь — но действительно непонятна цель. То есть какждый язык для чего-то нужен. Как пример: пролог, лисп, С и все остальное. У каждого своя ниша. А какую нишу ваш займет?
Удачи тебе, браток!
Re[2]: Мое видение того как можно разработать новый язык для
Здравствуйте, Glоbus, Вы писали:
G>Твое видение того как можно разработать новый язык для дотнет -> А на кой ляд он нужен. какие в нем будут преимущества перед уже существующими. Для каких задач будет применятся. Или это просто милое упражнение по теории компиляторов после прочтения книжки Ахо. Не сочтите вышеприведенную фразу за оскорбление — не хотел вас обидеть, клянусь — но действительно непонятна цель. То есть какждый язык для чего-то нужен. Как пример: пролог, лисп, С и все остальное. У каждого своя ниша. А какую нишу ваш займет?
Здравствуйте, Dr_Sh0ck, Вы писали:
D_S>Здравствуйте, Glоbus, Вы писали:
G>>Твое видение того как можно разработать новый язык для дотнет -> А на кой ляд он нужен. какие в нем будут преимущества перед уже существующими. Для каких задач будет применятся. Или это просто милое упражнение по теории компиляторов после прочтения книжки Ахо. Не сочтите вышеприведенную фразу за оскорбление — не хотел вас обидеть, клянусь — но действительно непонятна цель. То есть какждый язык для чего-то нужен. Как пример: пролог, лисп, С и все остальное. У каждого своя ниша. А какую нишу ваш займет?
D_S>здесь
Н-да, прилюбопытно. Но я вот думаю, а почему не дождаться того, что МС эти вещи реализует, если они есть в спецификации Шарпа 2. Ваще много философских вопросв. Например почему Мс не реализовал дефолтные параметры в настоящей реализации Шарпа. То же про интерфейсы. Наверное есть на то причины. они там тоже не последние лохи.
Удачи тебе, браток!
Re[4]: Мое видение того как можно разработать новый язык для
Здравствуйте, Glоbus, Вы писали:
G>Н-да, прилюбопытно. Но я вот думаю, а почему не дождаться того, что МС эти вещи реализует, если они есть в спецификации Шарпа 2. Ваще много философских вопросв. Например почему Мс не реализовал дефолтные параметры в настоящей реализации Шарпа. То же про интерфейсы. Наверное есть на то причины. они там тоже не последние лохи.
Не согласен. Во-первых этих вещей в спецификации нет. И врядли будут.
А что что в МС не лохи, это бесспорно так.
Но то, что в шарпе дейтсвительно отсутствуют некоторые удобные вещи, в принципе никак не конфликтующие с идеологией шарпа и CLR в целом, это факт.
И ведь если этого не сделано, это ж не значит, что МС — лохи
Если ты еще этого не заметил, то обращаю твое внимание, на факт, что МС порой ведет очень своеобразную политику...
Do not fake yourself ;)
ICQ#: 198114726
Re[5]: Мое видение того как можно разработать новый язык для
Здравствуйте, Dr_Sh0ck, Вы писали:
D_S>Здравствуйте, Glоbus, Вы писали:
G>>Например почему Мс не реализовал дефолтные параметры в настоящей реализации Шарпа. То же про интерфейсы. Наверное есть на то причины. они там тоже не последние лохи.
D_S>И ведь если этого не сделано, это ж не значит, что МС — лохи D_S>Если ты еще этого не заметил, то обращаю твое внимание, на факт, что МС порой ведет очень своеобразную политику...
Как хотите, а для меня очевидно, что отсутствие параметров по умолчанию в Си-шарпе — явный признак заговора против человечества!
Да здравствует ИМХО!
Re[2]: Мое видение того как можно разработать новый язык для
G>Твое видение того как можно разработать новый язык для дотнет -> А на кой ляд он нужен. какие в нем будут преимущества перед уже существующими. Для каких задач будет применятся. Или это просто милое упражнение по теории компиляторов после прочтения книжки Ахо. Не сочтите вышеприведенную фразу за оскорбление — не хотел вас обидеть, клянусь — но действительно непонятна цель. То есть какждый язык для чего-то нужен. Как пример: пролог, лисп, С и все остальное. У каждого своя ниша. А какую нишу ваш займет?
Здравствуйте, Glоbus, Вы писали:
G>Н-да, прилюбопытно. Но я вот думаю, а почему не дождаться того, что МС эти вещи реализует, если они есть в спецификации Шарпа 2.
1. Потому что их нет в Шпрп 2.
3. Потому что когда МС их реализует рак на горе свистеть разучится.
G> Ваще много философских вопросв. Например почему Мс не реализовал дефолтные параметры в настоящей реализации Шарпа. То же про интерфейсы. Наверное есть на то причины. они там тоже не последние лохи.
Это их проблемы. И лично я не хочу разгребать их проблемы.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, VladD2, Вы писали:
S>Какая жалость, что в C# нельзя применять атрибуты к фрагментам кода. Тогда бы все эти модные ключевые слова вводились бы вот так:
А между прочим прикольно, по крайне мере не надо писать __msil {}, да и расширяемость. Кстати, Андрей, мы говорили о запоминании имен, опять же конфликты имен. Вдруг кодогенератор использует несколько "ItemType" слов. А я в коде задействую только несколько, а другие будут мои, но совпадать с кодогенерационными.
Здравствуйте, Sinclair, Вы писали:
S>Какая жалость, что в C# нельзя применять атрибуты к фрагментам кода. Тогда бы все эти модные ключевые слова вводились бы вот так:
Для написания кода нужны ключевые слова. Атрибуты лучше подходят для управления генерацией кода. Использование их вместо ключевых слов приведёт только к замусориванию языка.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали: IT>Для написания кода нужны ключевые слова.
Это верно. IT>Атрибуты лучше подходят для управления генерацией кода.
Тоже верно. IT>Использование их вместо ключевых слов приведёт только к замусориванию языка.
Просто атрибут msil — неудачный пример.
... << RSDN@Home 1.1.2 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
IT>>Использование их вместо ключевых слов приведёт только к замусориванию языка. S>Просто атрибут msil — неудачный пример.
Ключевое слово __msil ещё более неудачный
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, VladD2, Вы писали:
S>Какая жалость, что в C# нельзя применять атрибуты к фрагментам кода.
Эээ... Амы то тут причем? Ничего не стоит выпарсивать атрибуты и выкидывать из из кода. Вопрос только в читабельности и поддержке студией. На такой код студия будет материться и комплит-ворд не будет работать.
А зачем тут атрибуты? Это и так прокатит. Если будет метапеременная, то ее ничего не стоит обработать:
[MetaVar]
bool isCondition = MetaConditionCall();
...
if (isCondition)
{
// Если isCondition == true - этот блок скомпилируется...
}
else
{
// Если isCondition == true - этот блок будет выброшен перед компиляцией...
}
Вместо атрибутов можно использовать синтаксис обычного кода. Нам ничего не стоит распознать в коде некотрый метод как атрибут. Но опять же проблемы с понятностью таких конструкций:
...
msil();
{
...
}
Что же касается мсил-а, то его можно будет получить только в полноценном компиляторе. Препроцессор этого не позволит.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Hello, "Sinclair"
> IT>Использование их вместо ключевых слов приведёт только к замусориванию языка. > Просто атрибут msil — неудачный пример.
Наверное, идея с добавление msil вставок сама по себе не самая лучшая.
Хотя, возможно, использования нескольких языков в рамках одного compilation unit была-бы очень удобной.
Все задачи одним языком не охватишь. Например, C# и VB.NET | JScript — первый достаточно удобен и традиционен, а во втором есть возможность использования позднего связывания. Конечно, в С# можно использовать reflection, но это избыточно и не удобно.
Собственно, эта задача решается и сейчас, но в целом, когда на вход компилятора подается много-языковой код, а на выходе мы имеем единую сборку — это удобно. Для того-же msil можно использовать концепцию partial классов из C# — класс описывается в нескольких файлах, а каждый из них уже может быть представлен своим языком.
Posted via RSDN NNTP Server 1.8 beta
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re: Мое видение того как можно разработать новый язык для до
Hello, "VladD2"
> Итак. Сначала о средствах разработки... >
Вот о средствах разработки. Может стоит определить в целом программу максимум и программу минимум?
Из программы минимум — на первом этапе можно получить гибкое средство рефакторинга исходного кода — получение метрик, проверка на best practices.
Да, в Whidbey уже что-то подобное встроено, но всегда есть возможности для улучшения.
По крайней мере это может привлечь людей с разными целями — кому-то достаточно рефакторинга, а кто-то будет продолжать разрабатывать язык.
Posted via RSDN NNTP Server 1.8 beta
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[2]: Мое видение того как можно разработать новый язык для
Здравствуйте, TK, Вы писали:
TK>Вот о средствах разработки. Может стоит определить в целом программу максимум и программу минимум?
Вроде бы и так определились. Программа максимум — это компилиятор.
Программа минимум... Да нет ее. Есть этапы. На первом этапе создание парсера в некое синтаксическое дерево (гибрид рефлекшода и абстрактного синтаксического дерева (AST)). Причем как отдельного компонента. Далее разработка АПИ модификации этого дерева. Ну, а там уже не за горами сначала препроцессор, а потом и компилятор.
TK>Из программы минимум — на первом этапе можно получить гибкое средство рефакторинга исходного кода — получение метрик, проверка на best practices.
Все это можно делать как ответвление от проекта сразу после создания парсера в дерево и АПИ по модификации этого дерева.
TK>Да, в Whidbey уже что-то подобное встроено, но всегда есть возможности для улучшения.
В Видби как всегда парсер скрыт, доступен не польностью и как всегда только вместе со студией.
TK>По крайней мере это может привлечь людей с разными целями — кому-то достаточно рефакторинга, а кто-то будет продолжать разрабатывать язык.
Возможно. Нужно более конкретно обрисовать кортину. Включить туда бенефиты, фичи, и план разработки с промежуточными этапами.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, TK, Вы писали:
TK>Наверное, идея с добавление msil вставок сама по себе не самая лучшая. TK>Хотя, возможно, использования нескольких языков в рамках одного compilation unit была-бы очень удобной.
Одно другому не противоричит. Идея с использованием нескольких языков здравая. Но сложно реализуемая. Для каждого языка нужен свой парсер.
МСИЛ же доступен, да и нужен только в компиляторе. Пока что про него нужно забыть... до проры... до времени...
TK>Все задачи одним языком не охватишь. Например, C# и VB.NET | JScript — первый достаточно удобен и традиционен, а во втором есть возможность использования позднего связывания. Конечно, в С# можно использовать reflection, но это избыточно и не удобно.
То что обсуждется здесь — это компайл-тайм фичи. Использовать VB.NET | JScript в ранмйм можно и так.
TK>Собственно, эта задача решается и сейчас, но в целом, когда на вход компилятора подается много-языковой код, а на выходе мы имеем единую сборку — это удобно. Для того-же msil можно использовать концепцию partial классов из C# — класс описывается в нескольких файлах, а каждый из них уже может быть представлен своим языком.
Нельзя. Мсил не парсится в общее AST. Он низкоуровневый язык. У него свое AST. Без компилятора его не реализовать. А с компилятором оно делается как неучить уроков.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Hello, "VladD2" > > TK>Наверное, идея с добавление msil вставок сама по себе не самая лучшая. > TK>Хотя, возможно, использования нескольких языков в рамках одного compilation unit была-бы очень удобной. > > Одно другому не противоричит. Идея с использованием нескольких языков здравая. Но сложно реализуемая. Для каждого языка нужен свой парсер. > То что обсуждется здесь — это компайл-тайм фичи. Использовать VB.NET | JScript в ранмйм можно и так. >
Главное, что-бы можно было подключать парсеры дополнительных языков. Тогда можно будет создавать partial классы написанные на разных языках.
Например — основной костяк класса пишется на C#. А там, где нужно поработать с COM или сделать несколько вызовов через reflection просто приписывается пару метолов на VB.
Posted via RSDN NNTP Server 1.8 beta
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Главное, что-бы можно было подключать парсеры дополнительных языков. Тогда можно будет создавать partial классы написанные на разных языках. TK>Например — основной костяк класса пишется на C#. А там, где нужно поработать с COM или сделать несколько вызовов через reflection просто приписывается пару метолов на VB.
Прямо языков нельзя. Но можно вычленить конкретные блоки и уже их парсить упрощенными парсерами. Упрощенными потму как это не полный парсер, а парсер отдельных лексем. Например функций, классов или частей методов. Если речь идет об отдельных исходных файлах, то это легче. Но опять таки процесса создания полноценного парсера для поддерживаемых языков не обойтись.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Мое видение того как можно разработать новый язык для
Здравствуйте, Dr_Sh0ck, Вы писали:
D_S>Здравствуйте, Glоbus, Вы писали:
G>>Н-да, прилюбопытно. Но я вот думаю, а почему не дождаться того, что МС эти вещи реализует, если они есть в спецификации Шарпа 2. Ваще много философских вопросв. Например почему Мс не реализовал дефолтные параметры в настоящей реализации Шарпа. То же про интерфейсы. Наверное есть на то причины. они там тоже не последние лохи.
D_S>Не согласен. Во-первых этих вещей в спецификации нет. И врядли будут. D_S>А что что в МС не лохи, это бесспорно так. D_S>Но то, что в шарпе дейтсвительно отсутствуют некоторые удобные вещи, в принципе никак не конфликтующие с идеологией шарпа и CLR в целом, это факт. D_S>И ведь если этого не сделано, это ж не значит, что МС — лохи D_S>Если ты еще этого не заметил, то обращаю твое внимание, на факт, что МС порой ведет очень своеобразную политику...
Старик, не в коем разе не хочу оспаривать все выше сказанное тобой, но мне все-таки интересно. Как дефолтные параметры и их отсутсвие увязывается с политикой МС. Ну или интерфейсы. то есть реально я считаю что в шарпе этих фич нехватает. Но вот вопрос к тебе лично — почему их там нет?
Удачи тебе, браток!
Re[6]: Мое видение того как можно разработать новый язык для
Здравствуйте, Glоbus, Вы писали:
G>Старик, не в коем разе не хочу оспаривать все выше сказанное тобой, но мне все-таки интересно. Как дефолтные параметры и их отсутсвие увязывается с политикой МС.
Я ж не имел ввиду их официальную политику Я имел ввиду "политику" выпустить продукт побыстрей, а потом дорабатывать его бесконечное количество раз. Временами объявляя об очередно "революции".
G>Ну или интерфейсы. то есть реально я считаю что в шарпе этих фич нехватает. Но вот вопрос к тебе лично — почему их там нет?
ИМХО потому что один из "отцов" решил, что раз с ему они не нужны, они, естессно, не нужны никому.
Do not fake yourself ;)
ICQ#: 198114726
Re[5]: Мое видение того как можно разработать новый язык для
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Glоbus, Вы писали:
G>>Н-да, прилюбопытно. Но я вот думаю, а почему не дождаться того, что МС эти вещи реализует, если они есть в спецификации Шарпа 2.
VD>1. Потому что их нет в Шпрп 2. VD>3. Потому что когда МС их реализует рак на горе свистеть разучится.
G>> Ваще много философских вопросв. Например почему Мс не реализовал дефолтные параметры в настоящей реализации Шарпа. То же про интерфейсы. Наверное есть на то причины. они там тоже не последние лохи.
VD>Это их проблемы. И лично я не хочу разгребать их проблемы.
А с чего ты решил что это их пороблеммы. И с чего ты решил что это ваще проблемы. То есть как лично по мне — это реально очень клевая задачка то что ты предлагаешь, но я просто цели не понимаю. А не понимаю потому что как я уже выше писал — Мс не лохи и им там наверное уж точно виднее что должно быть в языке а чего не должго, чем десяти энтузиастам, разводящим флейм о том как клево было бы убрать микрософт. Ты, старичела, не принимай на свой счет, но это реально категории того что мы бы с тобой начали строить космический корабль и сказали бы что до марса доберемся раньше чем НАСА. Потому мол что они там закостенели в своих догмах а мы — свежие молодые умы — их просто на запчасти разомкнем. То есть мне лично кажется, что дальше разговоров дело не пойдет хотя бы просто потому что нет надобности в этом вот новом языке. Не будет иметь коммерческого успеха. Да и просто по ресурсам не потянем. Задача архисложная и с организационной точки зрения скоординировать работу пары десятков людей при условии что все происходит на "коленке" и в свободное от пожрать/посрать время просто нереально.
PS Хотя с образовательной точки зрения очень очень очень интересная тема
Удачи тебе, браток!
Re[7]: Мое видение того как можно разработать новый язык для
Здравствуйте, Dr_Sh0ck, Вы писали:
D_S>Здравствуйте, Glоbus, Вы писали:
G>>Старик, не в коем разе не хочу оспаривать все выше сказанное тобой, но мне все-таки интересно. Как дефолтные параметры и их отсутсвие увязывается с политикой МС.
D_S>Я ж не имел ввиду их официальную политику Я имел ввиду "политику" выпустить продукт побыстрей, а потом дорабатывать его бесконечное количество раз. Временами объявляя об очередно "революции".
G>>Ну или интерфейсы. то есть реально я считаю что в шарпе этих фич нехватает. Но вот вопрос к тебе лично — почему их там нет?
D_S>ИМХО потому что один из "отцов" решил, что раз с ему они не нужны, они, естессно, не нужны никому.
Вай вай вай! Каку говоришь! Так и вижу энтузиаста с всклокоченными волосами, безумным взглядом и в растянутом свитере, шепчущего себе под нос чтото типа "Default параметры — сакс!!" и неистово кромсающего спецификацию шарпа. А не кажется ли вам, мой благородный друг, что не так все у МС тупо и лихо — захотел вырезал параметры дефолтные, захотел — не вырезал. как я уже говорил — для меня это загадка — их отсутсвие. Но все же. может стоит поискать некое логическое объяснение, которое снимет этот вопрос, а не писать свой язык.
Удачи тебе, браток!
Re[8]: Мое видение того как можно разработать новый язык для
Здравствуйте, Glоbus, Вы писали:
G>А не кажется ли вам, мой благородный друг, что не так все у МС тупо и лихо — захотел вырезал параметры дефолтные, захотел — не вырезал. как я уже говорил — для меня это загадка — их отсутсвие. Но все же. может стоит поискать некое логическое объяснение, которое снимет этот вопрос, а не писать свой язык.
Я поискал. Нечего более логичного мне в голову не пришло.
P.S. Прежде чем безоговорочно верить, что в МС в кульно и безглючно с первого раза, лучше бы сам подумал, зачем, например, есть просто делегаты, а есть мультикастделегаты... и т.д. и т.п.
Do not fake yourself ;)
ICQ#: 198114726
Re[6]: Мое видение того как можно разработать новый язык для
Здравствуйте, Glоbus, Вы писали:
G>А не понимаю потому что как я уже выше писал — Мс не лохи и им там наверное уж точно виднее что должно быть в языке а чего не должго
У них своя точка зрения. Прокт Шарпа делает человек всю жизнь занимавшийся Дельфми плюс тяжелое наследство Явы. Все фичи в том или ином виде уже есть в других языках и прекрасно себя зарекомедовали. Разве что метапрограммирование несколько ново, но и оно есть как отдельные продукты (тот же OpenC++).
G>но это реально категории того что мы бы с тобой начали строить космический корабль и сказали бы что до марса доберемся раньше чем НАСА.
Неверная аналогия. Ты слишком переоцениваешь трудозатраты на создания нового языка. В МС Шарпом занимались 7 человек на протяжении двух лет. Причем они занимались всем, от обвязки до компилятора и библиотек. Плюс к тому они писали на плюсах и без использования средств атоматизации.
Ну, и главное проект планируется многоэтапным. На первом этапе будет парсер. На втором препроцессор. А там уже видно будет. Уж препроцессор точно можно сделать.
G>Не будет иметь коммерческого успеха.
Я и не собираюсь с него деньги зарабатывать.
G> Да и просто по ресурсам не потянем.
По моим расчетом потяенем.
G> Задача архисложная
Ошибаешся...
G> и с организационной точки зрения скоординировать работу пары десятков людей
Вряд ли на первых порах будет столько. Дай бог чтобы хоть 4 человека наблалось.
G> при условии что все происходит на "коленке" и в свободное от пожрать/посрать время просто нереально.
Хоум делался на тех же условиях. Вот как-то живет.
G>PS Хотя с образовательной точки зрения очень очень очень интересная тема
О том и речь. Убытка точно от него не будет.
В общем, я точно им буду заниматься, вот только по-серьезному где-то после нового года. Так что вопрос "почему не нужно делать это проект" развивать больше не охота. Если интересно, то предлагаю перейти к обсуждению деталей коих не мало.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Мое видение того как можно разработать новый язык для
Здравствуйте, Glоbus, Вы писали:
G>Старик, не в коем разе не хочу оспаривать все выше сказанное тобой, но мне все-таки интересно. Как дефолтные параметры и их отсутсвие увязывается с политикой МС. Ну или интерфейсы. то есть реально я считаю что в шарпе этих фич нехватает. Но вот вопрос к тебе лично — почему их там нет?
Ребята создавали, скажам так, "чистый" язык. Дефолтные параметры несколько дублируют функциональность перегрузки. И так как перегрузка более чистая фича по видимому решили не делать. В Васике сделали и вроде все ОК. В общем, каприз. А любой капирз руководителя проекта становится палитикой фирмы.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Мое видение того как можно разработать новый язык для
Насчет 7 человек в МС я не знал, а в остальном полностью согласен и поддерживаю. Ну не интересно мне контролы на форму бросать ни прямыми, ни кручеными.
... << RSDN@Home 1.1.0 stable, слушаю — звезды >>
Re[9]: Мое видение того как можно разработать новый язык для
Здравствуйте, Dr_Sh0ck, Вы писали:
D_S>Здравствуйте, Glоbus, Вы писали:
G>>А не кажется ли вам, мой благородный друг, что не так все у МС тупо и лихо — захотел вырезал параметры дефолтные, захотел — не вырезал. как я уже говорил — для меня это загадка — их отсутсвие. Но все же. может стоит поискать некое логическое объяснение, которое снимет этот вопрос, а не писать свой язык.
D_S>Я поискал. Нечего более логичного мне в голову не пришло.
D_S>P.S. Прежде чем безоговорочно верить, что в МС в кульно и безглючно с первого раза, лучше бы сам подумал, зачем, например, есть просто делегаты, а есть мультикастделегаты... и т.д. и т.п.
А ваще почему бы не верить. Все-таки сколько бы на них говнище не лили контора клевая.
P.S
А действительно зачем мультикастделегаты?
Удачи тебе, браток!
Re[8]: Мое видение того как можно разработать новый язык для
Здравствуйте, beretta, Вы писали:
B>Здравствуйте, VladD2, Вы писали:
B>Насчет 7 человек в МС я не знал, а в остальном полностью согласен и поддерживаю. Ну не интересно мне контролы на форму бросать ни прямыми, ни кручеными.
А ты работу смени шоб не бросать. Хошь компиляторы — вон в 1С скоко вакансий.
Удачи тебе, браток!
Re[10]: Мое видение того как можно разработать новый язык дл
Здравствуйте, Dr_Sh0ck, Вы писали:
D_S>Здравствуйте, Glоbus, Вы писали:
G>>А ваще почему бы не верить. Все-таки сколько бы на них говнище не лили контора клевая.
D_S>А никто я и не пытаюсь. Просто одно другому не мешает.
G>>P.S G>>А действительно зачем мультикастделегаты?
D_S>Не "зачем", а delegate на C# — это и есть потомок мультикастделегата
Старик, ты че, издеваешся
Здравствуй Др_Шок, ты писал Глобусу
P.S. Прежде чем безоговорочно верить, что в МС в кульно и безглючно с первого раза, лучше бы сам подумал, зачем, например, есть просто делегаты, а есть мультикастделегаты... и т.д. и т.п.
А глобус у тебя спросил
P.S
А действительно зачем мультикастделегаты?
А ты ему что написал?
Прости за нескромный вопрос, ты че, понты решил передо мной поколотить. То есть я конечно понимаю, что если на районе скажу что не знаю что такое мултикаст делегаты меня пацаны заплюют, но все-таки ты бы хоть конву разговора пытался поддержать
Удачи тебе, браток!
Re[12]: Мое видение того как можно разработать новый язык дл
Здравствуйте, Glоbus, Вы писали:
G>Старик, ты че, издеваешся
G>Здравствуй Др_Шок, ты писал Глобусу
G>P.S. Прежде чем безоговорочно верить, что в МС в кульно и безглючно с первого раза, лучше бы сам подумал, зачем, например, есть просто делегаты, а есть мультикастделегаты... и т.д. и т.п.
G>А глобус у тебя спросил
G>P.S G>А действительно зачем мультикастделегаты?
G>А ты ему что написал?
А что тебе, собссно говоря, не понятно? Ты что не знаешь зачем _делегаты_ ? Если так, то ето скорее в MSDN тебе объяснят...
Суть моего поста:
лучше бы сам подумал, зачем, например, есть просто делегаты, а есть мультикастделегаты... и т.д. и т.п.
Заключалась не в том, зачем они нужны вообще, а в том, почему существуют классы просто _делегата_ и мультикаст делегата.
G>Прости за нескромный вопрос, ты че, понты решил передо мной поколотить. То есть я конечно понимаю, что если на районе скажу что не знаю что такое мултикаст делегаты меня пацаны заплюют, но все-таки ты бы хоть конву разговора пытался поддержать
Сделаю вид, что я этого не слышал
P.S. Просто совет — поменьше эмоций.
Do not fake yourself ;)
ICQ#: 198114726
Re[6]: Мое видение того как можно разработать новый язык для
The stars so gaily glistened... (Mon, 22 Dec 2003 12:00:09 GMT @541)
...while the fading voice of Glоbus whispered through the darkness:
G> как я уже выше писал — Мс не лохи и им там наверное уж точно виднее что G> должно быть в языке а чего не должго, чем десяти энтузиастам, разводящим
В J++, .Net и C# принимал участие очень известный человек.
Ведущий разработчик Turbo Pascal.
Потом ведущий архитектор Delphi
Так же занимался Обероном (предпоследний язык Н. Вирта)
Последний язык вирта — Component Pascal (www.oberon.ch)
Вроде-бы описание самого языка занимает 20 страниц.
Правда вопрос насколько RTL ляжет поверх .NET.
Еще вопрос — нужно ли начинать все с нуля — или можно подключиться например
к www.dotgnu.org/pnet.html ?
Compiler Generator , generates a Recursvie Decent Predictive Parser for LL(1) grammar , Semantic Rules are supported through Translation Schemes, Also include A Lexical Analyzer Generator which generates a lexical table for given token defintion , give it a try
... << RSDN@Home 1.1.0 stable >>
Re: Мое видение того как можно разработать новый язык для до
Spart is designed to bring you parser capabilites quickly directly into your code. While it is not suited for creating parsers for entire language like C,C++, it is very effective for building micro-grammars in your code.
When you need to build a new parser, there are existing solution: a combination of ....Parse (like int.Parse) calls, or using regular expression (Regexp class) or a combination of both. However, these tools do not scale well when attempting to write more complex parsers: maintenance and readability become ackward.
So, as for Spirit, one of the main objective of Spart is to let you build easily grammar in C#.
... << RSDN@Home 1.1.0 stable >>
Re[2]: Мое видение того как можно разработать новый язык для
AVK>Вот и надо придумать способ записать тоже самое, но более внятным языком. В приведенном примере я постарался это сделать. Буду рад увидеть более читабельные варианты.
а такой вариант понятнее?
// Генерирует immutable класс для интерфейсов, помеченных атрибутом Immutable
<% foreach(Type type in xxx.FindMarkedByImmutable()) { %>
public class <%=type.Name%>Immutable : <%=type.FullName%>
{
<% foreach(PropertyInfo info in xxx.FindProperties(type)) { %>
private <%=info.MemberType%> _<%=info.Name%>;
public <%=info.MemberType%> <%=info.Name%>
{
get { return _<%=info.Name%>; }
}
<% } %>
public <%=type.Name%>Immutable(
<% int pos=0; foreach(PropertyInfo info in xxx.FindProperties(type)) { %>
<%=info.MemberType%> param<%=info.Name%><%= ++pos<xxx.FindProperties(type).Length ? ", " : "" %>
<% } %>
)
{
<% foreach(PropertyInfo info in xxx.FindProperties(type)) { %>
_<%=info.Name%> = param<%=info.Name%>;
<% } %>
}
}
<% } %>
AVK>Пример с атрибутами меня не воодушевил, а точнее совсем не понравился. Мешает все в одну кучу — непонятно где собственно код, а где его генерация, сразу сказать какой код получится в результате генерации крайне сложно.
по roadmap-у шаблон должен сидеть в custom build tool. А к custom build туулзе должен быть еще add in, который бы опрашивал у пользователя папочки в которых искать сборки с типами помеченными Immutable. Но фиг с интерграцией — можно обойтись и консольным bat-файлом и один раз добавить в прoект сгенерированные файлы.
еще большая проблема — нехватает Intellisense студийного когда такой шаблон пишешь.