Здравствуйте, V.Petrovski, Вы писали:

Кстати, ты каким образом парсер делал? Yacc-ом, еще чем, или вручную?

Здравствуйте, 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>и разработка комилятора/парсера должно быть дело для профи... а профи все на с++ пишут (шутка)

Профи уже давно ползут с С++

Здравствуйте, VladD2, Вы писали:

VP>>Замутить то можно, но у меня со свободным временем напряги.
VP>>Ну чем могу помогу в свободное время.

VD>Если бы ты знал насколько хренова со временем у меня.
VD>Но все же хочется заняться чем-то для души.

А вот и правда — ты прикинь примерно сроки, которые на это понадобятся. Может просто препроцессинг нормальный прикрутить?

Здравствуйте, VladD2, Вы писали:

Две новые фичи в план...

1. Компилятор строется как ядро позволяющее поключать плагины. Это позволит добавлять ресерчные фичи не меняя основного проекта. И позволит сздавать конкурирующие реализации идей. Примерное видение:

// Подглючаем модуль оптимизации
[assembly : RSDN.Compiler.Use("MyOptimizationsPac")]
// Подглючаем модуль метапрограммирования
[file     : RSDN.Compiler.Use("RSDN.MetaLangPac")]

2. Вставки на МСИЛ-е. Это позволит делать различные оптимизации, так же как это было возможно на С++ или Дельфи. Вставляем в код секцию __msil и получаем доступ к телу.

void MySomeHack(int i)
{
  i++;
    __msil
    {
      ldloc.0
      ldloc.0
      add
      ...
    }
    ...
}

Здравствуйте, AndrewVK, Вы писали:

AVK>Так может начать с малого — с написания парсера. Это куда менее трудоемко, а результат полезен не только в компиляторах.

Собственно именно так я и планирую сделать. Если внимательно прочесть мой план, то можно заметить, что парсер стоит первой задачей.

AVK>ЧТо то меня подобная перспектива пугает. В янусе вон куда более простые вещи бывает месяцами реализовать не можем, а здесь оптимизатор.

Еще раз. Джит делает львиную долю оптимизаций. Именно по этому я и говорю о компиляции в мсил и даже не обсуждаю вариант с полноценным компиляторов в машинный код.

Ну, и именно поэтому я хочу сделать открытый проект. Это даст возможность работать параллельно.

Кстати, классно было бы сделать компилятор с плагинами (вроде идея Ведмедя). Тогда бы доработка упростилась бы до нельзя. А для этого нужно просто все делать в компонентном стиле. И помнить о плагинах. По сути парсер будет некой компонентной моделью позволяющей программно анализировать и изменять дерево разбора. Потом найдется орел который напишит "плагин-оптимизатор того то", а еще чуть погодя "плагин-оптимизатор сего-то"... Глядишь так мы вообще в законодатили компиляторной мысли выйдем, и Москву переименуют в Олд РСДН.


AVK>Прямой нет.

А зачем она? Мы сможем компилировть любой исходник. Как свой, так и Шарповый. Что еще надо?

AVK> Если вдруг по каким то причинам мне понадобится отказаться от компилятора на существующем проекте в пользу стандартного, сделать мне это будет очень сложно. Это плюс для коммерческого проекта и минус для некоммерческого.

Не, ну, это уже из области фантастики. В любом случае можно всегда заморозить развитие сборки созданной на ресерчном компиляторе, отнаследоваться и развивать класс на обычном компиляторе. Ведь по сборкам мы будет полностью совместмы.

VD>>Гы. Вот тут вообще фигня. Новые фичи мы уж точно будем вставлять быстрее МС.

AVK>Не уверен. Наверное все же программеры в МС не зря свой хлеб едят.

Они остарожничают. А у нас ресерчный язык. Так что нет администратевного гнета. Если сделать все на плагинах, так вообще добавление новых фич будет довольно простым занятием.

AVK>Команда, разрабатывающая шарп как минимум не меньше той что у нас и не хуже квалификацией. Почему у нас будет получаться лучше?

Что касаемо квалификации, то да. А по размеру... Все зависит от народа и задора. Хотя не в размере счастье.

VD>>А ето 80% компилятора.

AVK>Нет конечно. Самым сложным всю жизнь был семантический, а не синтаксический анализатор.

Ошибаешся. 80% ошибкок и тракха именно синтаксис. К тому, же полноценный парсер просто обязан поддерижвать семантический анализ. Так как иначе во многих случаях вообще нельзя квалифицировать некоторые конструкции.

AVK>Но при этом привнесет и вышеперечисленные недостатки. Честно говоря больше всего меня пугают 3 и 4 пункт. Настолько пугают что я готов обойтись без предполагаемых фич.

Короче. Я так понимаю, что нам обоим нужен качественный не ограниченный лицензиями, и понятный нам парсер. Я прав? Значит уже есть над чем тудиться вместее. Предлагаю начать!

Вот только серьезно я этим смогу заняться после нового года. Веренее после сдачи РСДН-а №6. Так как иначе мы его завалим.

AVK>И еще меня пугает попытки добавить что то уже сейчас даже не подумав о последствиях. Ну вроде вызова методов дедушки через голову родителя.

Ну, это вообще не вопрос. Делать будем только после всестороннего обсасывания. И делать будем на базе плагинной технологии. Чтобы можно было послать тех кто хочет "именно эту фичу"... делать плагин.

Так что нужно корошенько продумать вопрос о плагинизации.

Здравствуйте, VladD2, Вы писали:

VD>

VD>void MySomeHack(int i)
VD>{
VD>  i++;
VD>    __msil
VD>    {
VD>      ldloc.0
VD>      ldloc.0
VD>      add
VD>      ...
VD>    }
VD>    ...
VD>}
VD>

Вот только не надо этих сишных префиксов

void MySomeHack(int i)
{
i++;
ilasm
{
ldloc.0
ldloc.0
add
...
}
...
}

Здравствуйте, Воронков Василий, Вы писали:

ВВ>А вот и правда — ты прикинь примерно сроки, которые на это понадобятся.

Пол года-год.

ВВ> Может просто препроцессинг нормальный прикрутить?

Мне это не интересно. Это полумера. Эдак я могу просто испоьзовать препроцессор от С++.

Здравствуйте, VladD2, Вы писали:

VD>Кстати, классно было бы сделать компилятор с плагинами (вроде идея Ведмедя). Тогда бы доработка упростилась бы до нельзя.

Не знаю. Все таки идея компилятора меня не увлекает. А с плагинами особенно, поскольку породит море несовместимых исходников.

AVK>>Прямой нет.

VD>А зачем она?

См. ниже

AVK>> Если вдруг по каким то причинам мне понадобится отказаться от компилятора на существующем проекте в пользу стандартного, сделать мне это будет очень сложно. Это плюс для коммерческого проекта и минус для некоммерческого.

VD>Не, ну, это уже из области фантастики.

Почему? Вот предположим начал я писать что то на самопальном компиляторе, потом от МС вышло то что мне больше понравилось/начальство заставило. С собственным компилятором у меня перейти просто не получится. Препроцессор кстати такой проблемы решен.

AVK>>Не уверен. Наверное все же программеры в МС не зря свой хлеб едят.

VD>Они остарожничают. А у нас ресерчный язык. Так что нет администратевного гнета.

Знаешь, они наверное все таки не зря осторожничают.

AVK>>Нет конечно. Самым сложным всю жизнь был семантический, а не синтаксический анализатор.

VD>Ошибаешся. 80% ошибкок и тракха именно синтаксис.

Не знаю, меня учили другому.

VD>К тому, же полноценный парсер просто обязан поддерижвать семантический анализ. Так как иначе во многих случаях вообще нельзя квалифицировать некоторые конструкции.

Например?

Здравствуйте, VladD2, Вы писали:

ВВ>>А вот и правда — ты прикинь примерно сроки, которые на это понадобятся.
VD>Пол года-год.

Полгода спорадической работы по выходным?

ВВ>> Может просто препроцессинг нормальный прикрутить?
VD>Мне это не интересно. Это полумера. Эдак я могу просто испоьзовать препроцессор от С++.

Ну на основе своего препроцессора можно и как-нибудь новые фички реализовать

Пока без комментариев, просто кусочек кода

// Генерирует типизированные списки для всех интерфейсов, наследников IList
metatemplate TypedList<project/interface[BaseInterfaces[Name == "System.Collections.IList"]]>
{
    public class <./Name>Implementation : CollectionBase, <./Name>
    {
        <./Name> this[int index]
        {
            get { return (<./Name>)List[index]; }
        }
    
        public void Add(<./Name> item)
        {
            List.Add(item);
        }
        
        ...
    }
}

// Генерирует immutable класс для интерфейсов, помеченных атрибутом Immutable
metatemplate ImmutableClass<project/interface[Attribute[Name == "ImmutableAttribute"]]>
{
    public class <./Name>Implementation : <./Name>
    {
        <foreach (./Property)>
        private <./Type> _<./Name>;
        
        public <./Type> <./Name>
        {
            get { return _<./Name>; }
        }
        <endforeach>
        
        public <./Name>Implementation(
            <foreach (./Property, ", ")>
            <./Type> param<./Name>
            <endforeach>
        )
        {
            <foreach (./Property)>
            _<./Name> = param<./Name>;
            <endforeach>
        }
    }
}

Здравствуйте, Воронков Василий, Вы писали:

ВВ>А вот и правда — ты прикинь примерно сроки, которые на это понадобятся. Может просто препроцессинг нормальный прикрутить?

Смотря на что. Пару-тройку Владо-дней на генерацию идей и ещё 3-4 человеко-года на их реализацию.

Здравствуйте, VladD2, Вы писали:

VD>Ну, по сравнению с Видби визаул-ассист просто детский лепет. Я уже перестал им пользоваться. А парсер как раз и будет доступен если он будет менеджед.

Подскажите плиз, что такое Видби и где его взять?

Спасибо.

A>>еще один аргумент: с++ — намного легче щас перевести под другие платформы...

VD>Без рантайма первеводить дотнет нет смысла. Да и вообще нет смысла. Так что где будет тот же Моно и мы будем. А где нет, там и не надо.

Вообще, по-моему, как только проект более-менее сформируется, имеет смысл законтачить с моновцами. Мало ли чего они там подбросят. Может, пропиарят немного на своём сайте.

Да и по-любому в Роторе тоже стоит засветиться. Как ни крути, а под ихнюю специфику проект попадает. Премию не премию, а всё-таки подружиться полезно. Можно консультироваться потом по специальным вопросам.


В любом случае престиж от таких засветок лично ждя участников проекта будет очень хороший. Дескать, я, там, Влад такой-то, мало того что большой босс в RSDN, но ещё и сотрудничаю с Mono и Microsoft SSCLI. У-у-у, сразу скажут потенциальные работодатели, платим тебе ещё штуку баксов.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, V.Petrovski, Вы писали:

VD>Кстати, ты каким образом парсер делал? Yacc-ом, еще чем, или вручную?

Это было в воремена beta 1 пришлось прикрутить тогда еще JCUP и JFlex для генерации C# кода.

Но чтобы этот парсер шустрым был лучше всего писать его рекурсивным с возможностью
заглядования на К символов. JavaCC позволяте писать парсер в таком виде

TOKEN :
{
  < LPAREN: "(" >
| < RPAREN: ")" >
| < LBRACE: "{" >
| < RBRACE: "}" >
| < LBRACKET: "[" >
| < RBRACKET: "]" >
| < SEMICOLON: ";" >
| < COMMA: "," >
| < DOT: "." >
}


void ArrayDimsAndInits() :
{}
{
  LOOKAHEAD(2)
  ( LOOKAHEAD(2) "[" Expression(new Vector()) "]" )+ ( LOOKAHEAD(2) "[" "]" )*
|
  ( "[" "]" )+ ArrayInitializer()
}

void ArrayInitializer() :
{}
{
  "{" [ VariableInitializer() ( LOOKAHEAD(2) "," VariableInitializer() )* ] [ "," ] "}"
}

void Expression(Vector vector) :
{
    Token token1 = getToken(1);
}
{
  ConditionalExpression() [ AssignmentOperator() Expression(new Vector()) ]
    {
        Token token2 = getToken(0);
        Token token3 = token1;
        do
        {
            vector.addElement(token3);
            if(token3 != token2)
                token3 = token3.next;
            else
                return;
        } while(true);
    }
}

Здравствуйте, IT, Вы писали:

ВВ>>А вот и правда — ты прикинь примерно сроки, которые на это понадобятся. Может просто препроцессинг нормальный прикрутить?

IT>Смотря на что. Пару-тройку Владо-дней на генерацию идей и ещё 3-4 человеко-года на их реализацию.

А что такое Владо-день? Чем он отличается от Васе-дня?

Здравствуйте, VladD2, Вы писали:

VD>Две новые фичи в план...

VD>1. Компилятор строется как ядро позволяющее поключать плагины. Это позволит добавлять ресерчные фичи не меняя основного проекта. И позволит сздавать конкурирующие реализации идей. Примерное видение:
VD>

VD>// Подглючаем модуль оптимизации
VD>[assembly : RSDN.Compiler.Use("MyOptimizationsPac")]
VD>// Подглючаем модуль метапрограммирования
VD>[file     : RSDN.Compiler.Use("RSDN.MetaLangPac")]
VD>

А как разрешать конфликты синтаксиса для плагинов ?

C Уважением, Andir!

Здравствуйте, AndrewVK, Вы писали:

AVK>Пока без комментариев, просто кусочек кода

Только не так! Пожалуйста! Вся прелесть такого читабельного языка как С# пропадает.

Здравствуйте, AndrewVK, Вы писали:

AVK>Вот только не надо этих сишных префиксов

Не, тут ты не прав. Перфиксы это не сишные. Это способ создать конструкцию не конфликтующую с идентификаторами в приложениях. Дело в том, что ilasm или msil должны будут стать ключевыми словами. А это сразу приведет к тому, что код использующий их в качестве идентификаторов перестанет компилироваться и наш компилятор будет несовместим с Шарпом сверху вниз. Есть соглашение по которому двойное подчеркивание зарезервировано для компилятора и не может использоваться для обозначения идентификаторов. Именно по этому __ilasm или __msil.

Например, у МС есть недукументированное ключевое слово __arglist. Называно именно по этим соображениям.

Попробуй создать переменную:

        int __arglist;

У нас просто нет другого выхода.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Полгода спорадической работы по выходным?

Так предпологается, что не одни человек будет работать. Темболее что кое-какие наработки уже есть. Да и не малый это срок.

ВВ>Ну на основе своего препроцессора можно и как-нибудь новые фички реализовать

Лучше уж реализовать свои фичи на основе нового языка.

Здравствуйте, IT, Вы писали:

IT>Смотря на что. Пару-тройку Владо-дней на генерацию идей и ещё 3-4 человеко-года на их реализацию.

А что такое человек?