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

C>Понимаешь, портабельность .NET приложений сейчас примерно равна
C>портабельности Mono (DotGNU не считаем, OK?). Так что, делаем выводы.

О чем делаем выводы?
В очередной раз фигею с тебя.

Andrei N.Sobchuck wrote:
> C>Так для обычной рефлексии много особо ничего и не надо. Вот Emit на D не
> C>сделать в принципе.
> btw, Совсем недавно любители Singularity, мне тут доказывали, что ни
> emit ни динамическая загрузка кода никому нафиг не нужны и даже вредны.
Как же мы об этом забыли

Ну ничего, добавят их в Singularity 2 и они снова станут замечательными
и абсолютно необходимыми фичами.

C>Я после одного проекта на семерке теперь при упоминании слов Symbian OS
C>стараюсь убежать как можно дальше Так что как там теперь — не знаю.
Поддерживаю целиком и полностью.

За ссылку — спасибо. Вот только вот эта строчка

This will definitely ease the porting of existing C++ application on Symbian OS (take care that you won’t be able to mix exception and the current Leaves/Trap).

Означает что толком C++ я смогу использовать только в отдельном потоке или процессе — который не взаимодействует с ОС вообще. Так что грош цена такому улучшению .

VladD2 wrote:
> C>http://www.xref-tech.com/xrefactory/emacs.html — вот тут много скриншотов.
> Зачем мне скриншоты "вообще"?
Там видно какие есть фичи.

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

> C>Переименование там работает секунды. Ну может секунд 10 максимум на
> C>больших проектах.
> 10 это уже никода не годно. Да и не верю, я что на больших проектах это
> будет 10 сек. 5 минут более реальная цифра. Или это будет не точный
> поиск. Правда сморя конечно что называть большим проектом.
Ты когда-нибудь слышал про кросс-индексы исходников? Так вот, XRef их
строит, поэтому там есть вкладка "usages", которая обновляется когда ты
двигаешься по коду.

Переимнование я лично проверял на достаточно большом проекте — работало
быстро.

Left2 wrote:
> This will definitely ease the porting of existing C++ application on
> Symbian OS (take care that you won’t be able to mix exception and the
> current Leaves/Trap).
Может они имеют в виду, что в пользовательском коде нельзя их смешивать?

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

FR>>На D можно вполне повторить.

VD>Ну, так повтори. Интересно глянуть.

Ну завал у меня по работе
Как буду дальше D ковырять попробую.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

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

C>>Так для обычной рефлексии много особо ничего и не надо. Вот Emit на D не
C>>сделать в принципе.

ANS>btw, Совсем недавно любители Singularity, мне тут доказывали, что ни emit ни динамическая загрузка кода никому нафиг не нужны и даже вредны.

Смотря куда. В ядро и драйверы — не стоит! А в прикладные проги — естественно стоит и даже практически необходимо.

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

C>VladD2 wrote:
>> C>А Влад тут говорит, что Mono — это rulez
>> Можно ссылку? Или ты о каком Владе говоришь?
C>О тебе, о ком же еще. Кто-то тут же хвалился портабельностью Nemerle.

C>Вот сделали бы Nemerle для LLVM — было бы круто.

А чем LLVM лучше Mono?

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

K>>ИМХО, это гипербола. Всё-таки лучше для Nemerle написать макрос (встроенный yacc) и юзать его, чем вручную на Nemerle писать лексический и синтаксический анализаторы.
WH>Ручками проще. Я пробовал.

LL(1) парсер методом синтаксического спуска? Или недо-LR с приоритетом операций? Всё это тяжело пишется и медленно работает. Генератор даёт гораздо более совершенный парсер, без множества граблей (хотя некоторые остаются). Да и проще описать грамматику и получить готовый парсер, чем писать грамматику (всё равно придётся) и по ней ручками долбить парсер.

Проблема yacc в том, что он yacc, а не в том, что он compiler-compiler. Можно те же вещи сделать удобнее.

Андрей Хропов wrote:
>> > C>А Влад тут говорит, что Mono — это rulez
>> > Можно ссылку? Или ты о каком Владе говоришь?
> C>О тебе, о ком же еще. Кто-то тут же хвалился портабельностью Nemerle.
> C>Вот сделали бы Nemerle для LLVM — было бы круто.
> А чем LLVM лучше Mono?
Очень многим. Во-первых, LLVM это Low-Level Virtual Machine, то
есть оно достаточно низкоуровневое (там есть даже поддержка вставки
ассемблерных инструкций), но при этом может быть использовано и в
верифицируемом режиме. Во-вторых, LLVM поддерживает обычную статическую
компиляцию. В-третьих, LLVM поддерживает и режим работы с JIT/HotSpot.
В-четвертых, LLVM скоро синтегрируется с GCC и будет работать на всем,
что только существует в природе.

В-пятых, это единственная распространенная VM без идиотской поддержки
ООП в наборе инструкций. И это мне больше всего нравится.

VladD2 wrote:
> C>Понимаешь, портабельность .NET приложений сейчас примерно равна
> C>портабельности Mono (DotGNU не считаем, OK?). Так что, делаем выводы.
> О чем делаем выводы?
> В очередной раз фигею с тебя.
Ну как бы... Если ты хвалишь портабельность Nemerle, то это
автоматически означает, что ты хвалишь Mono.

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

K>LL(1) парсер методом синтаксического спуска? Или недо-LR с приоритетом операций? Всё это тяжело пишется и медленно работает.
Если это делать на С++ то да.
А так немерле написан на немерле. И никаких компиляторов компиляторов там не используется.

K>Генератор даёт гораздо более совершенный парсер, без множества граблей (хотя некоторые остаются).
Заставить такой парсер (особенно LR) выдавать человекочитаемые сообщения об ошибках задача не тривиальная.

K>Да и проще описать грамматику и получить готовый парсер, чем писать грамматику (всё равно придётся) и по ней ручками долбить парсер.
А зачем?
Болие того грамматика всех языков программирования где есть требование предварительного объявления переменных является как минимум контекстно зависимой. А для КЗ грамматик не существует эффективных парсеров.
Так что в любом случае описывается не грамматика языка, а грамматика надмножества языка. И далие неформальными правилами (которые почемуто называют семантикой ) отсекаются невалидные строки.

K>Проблема yacc в том, что он yacc, а не в том, что он compiler-compiler. Можно те же вещи сделать удобнее.
Я пробовал разнае КК. На немерле ручками всеравно проще писать.
А когда дело доходит до генерации однотипных методов в АСТ то все эти КК вобще в пролете. Ибо в принципе не умеют.

WolfHound wrote:
> Я пробовал разнае КК. На немерле ручками всеравно проще писать.
> А когда дело доходит до генерации однотипных методов в АСТ то все эти КК
> вобще в пролете. Ибо в принципе не умеют.
А ANTLR пробовал? Мне действительно интересно, скоро парсер для нехилого
языка придется писать.

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

FR>>На D можно вполне повторить.

VD>Ну, так повтори. Интересно глянуть.

Пока держи что попроще, взял с твоей ссылки на linq вот этот пример

public void Linq1() {
    int[] numbers = { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 };

    var lowNums =
        from n in numbers
        where n < 5
        select n;

    Console.WriteLine("Numbers < 5:");
    foreach (var x in lowNums) {
        Console.WriteLine(x);
    }
}

вот что получилось

import std.stdio;

class from(alias V, alias TA)
{   
    alias typeof(TA[0]) T;
    alias T[] A;
    
    A seq;
    bool delegate() cond;
    
    this()
    {
        this.seq = TA;
    }
    
    from where(bool delegate() cond)
    {
        this.cond = cond;
        return this;
    }
    
    A select(T delegate() exec)
    {
        A result;
        foreach(v; seq)
        {
            V = v;
            if(cond()) 
            {
                result ~= [exec()];
            }    
        }
        return result;
    }
         
}


void main()
{
    auto numbers = [5, 4, 1, 3, 9, 8, 6, 7, 2, 0];
    
    int x;   
    auto r = (new from!(x, numbers))
                .where({return x < 5;})
                .select({return x;});
    
    writefln(r);
}

конечно корявей и плохо то, что используется внешняя переменная, но вполне терпимо (да и улучшить тут многое можно).

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

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

K>>LL(1) парсер методом синтаксического спуска? Или недо-LR с приоритетом операций? Всё это тяжело пишется и медленно работает.
WH>Если это делать на С++ то да.
WH>А так немерле написан на немерле. И никаких компиляторов компиляторов там не используется.

А пофигу, C++, Nemerle — всё равно писать. Да, на Немерле мы в 3 раза быстрее напишем. А вот с помощью КК пожно в inf раз быстрее сделать.

K>>Генератор даёт гораздо более совершенный парсер, без множества граблей (хотя некоторые остаются).
WH>Заставить такой парсер (особенно LR) выдавать человекочитаемые сообщения об ошибках задача не тривиальная.

На самом деле, диагностика ошибок — задача во всём компиляторостроении нетривиальная (на самом деле, огромная заслуга Москаля в том, что он сумел вывод типов совместить с нормальными сообщениями об ошибках). Делать её ручками на намного проще. Да и проблему я вижу не в КК вообще, а именно в кривизне yacc.

K>>Да и проще описать грамматику и получить готовый парсер, чем писать грамматику (всё равно придётся) и по ней ручками долбить парсер.
WH>А зачем?
WH>Болие того грамматика всех языков программирования где есть требование предварительного объявления переменных является как минимум контекстно зависимой. А для КЗ грамматик не существует эффективных парсеров.
WH>Так что в любом случае описывается не грамматика языка, а грамматика надмножества языка. И далие неформальными правилами (которые почемуто называют семантикой ) отсекаются невалидные строки.

Согласен. Но только гораздо проще, если это надмножество парсится автоматически сгенерированным парсером, а затем по некоторым продукциям (их будет очень немного на самом деле) мы выполнем семантическое действие. Ну и дальше обход AST — без этого никак.

WH>Я пробовал разнае КК. На немерле ручками всеравно проще писать.

Какие, интересно знать? Вот мне тоже ни один не подошёл — так я свой написал на C# (не поделюсь). Теперь на Nemerle делаю ещё круче (поделюсь, когда сделаю).

WH>А когда дело доходит до генерации однотипных методов в АСТ то все эти КК вобще в пролете. Ибо в принципе не умеют.

А вот у меня в ближайших планах сделать КК, который генерит парсеры, автоматически (в большинстве случаев) создающие AST. Плюс ещё нужно ручками несколько функций написать, чтобы некоторые нетривиальные узлы построить. Работа идёт потихоньку, теоретическая база есть, осталось дело за реализацией.

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

FR>В общем это:
FR>

FR>Нет, я утверждаю (точнее предпологаю, оставляя поле для сомнения), что на С++ и Ди невозомжно сгенерировать методы нужной сигнатуры по описанию заданному ссылкой на тип.

FR>вроде получается:

Еще раз. Это не герерация методов. Это создание гибких обобщений. А это разные вещи, хотя и позволяющие решать ряд общих задач.

FR>f это фукция сгенерированная по ссылке на тип функции tst

Но генератор ведь не виртуальный.

FR>Ну а в частных случаях вроде фабрики это разрешимо по другому.

Пока что чистого решения я не увидил. Шаблон с переменным числом параметров — это конечно круто, но не совсем то что хотелось бы.

Аналогом такого шаблона является простейший макрос с перменным числом параметров (последний параметр помеченный как params). Вот только это не совсем то что хотелось бы.

FR>Просто надо еще C++ ихний ставить чтобы линкер и т. п. были доступны.

Странная политика. Если они хотят людей привлечь, то нужно был сделать удобный инсталлятор. Уж если не с IDE, то хотя бы с простой поддержкой компиляции из командной строки. Как, например, в VS... запускаешь батричек и получаешь все что ужно в командной строке.

VD>>Да, это лучше чем С++, но все равно до заданных вручную им далеко:

FR>Гораздо лучше. И самый прикол что в D тоже можно вручную задавать. В том моем примере это легко добавить, плюс нужно добавить проверки на то что соответствующий класс является наследником соответствующего интерфейса, и выдачу сообщения об ошибке.

Интересно было бы поглядеть, но что-то мне подсказывает, что это опять будет плясками с бубном, а не прямым и красивым решением. А вот эти пляски мне больше всего не нравятся. По мне так лучше или наличие прямого решения, или полное его отсуствие.

FR>В D многие вещи которые в C++ делаются через ж... встроенны в язык, в общем D идет вполне нормальном направлении.

А мне кажется, что как раз направление не верное. Это путь С++. А он кривой. Причем идеологически.

FR>>>Это да. Но смотря на некорые вещи в D (tupleof и вообще туплы) кажется что вполне возможно добавить в язык статический "генератор классов".

VD>>А не проще ли его добавить напрямую, а не через зад?

FR>Так оно и добавлено напрямую это ключевое слово языка.

Я про "статический "генератор классов"".

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

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

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

C>Ты когда-нибудь слышал про кросс-индексы исходников? Так вот, XRef их
C>строит, поэтому там есть вкладка "usages", которая обновляется когда ты
C>двигаешься по коду.

Я не просто что-то слышал. Я на практике занимаюсь похожими вещами. И знаю что такое С++. Исходя из этого я точно знаю чем это все закончится. Будут или жудчашие тормоза, или глюки. Все IDE которые я видел до этого выбирали глюки.

Все индесы и т.п. прийдется перестраивать при малейших изменениях. Учитывая навороты метапрограммирвоания сделать все это инкрементально для С++ практически нереально.

C>Переимнование я лично проверял на достаточно большом проекте — работало
C>быстро.

Быстро — это сколко? Когда в бэтах VS 2005 переименование занимало всего каких-то 4-5 секунд — это было нестерпимо, и я зачастую выбирал замену по контексту. А 10+ это уже совсем не быстро. Тут уже в стиле F2, поправил имя, нажал ввод уже не прокатит. Три изменения — минута. А когда одно изменение может привести к генерации совсем другого кода, то это вообще смертельные танцы.

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

FR>Пока держи что попроще, взял с твоей ссылки на linq вот этот пример

FR>

FR>public void Linq1() {
FR>    int[] numbers = { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 };

FR>    var lowNums =
FR>        from n in numbers
FR>        where n < 5
FR>        select n;

FR>    Console.WriteLine("Numbers < 5:");
FR>    foreach (var x in lowNums) {
FR>        Console.WriteLine(x);
FR>    }
FR>}
FR>

...

FR>конечно корявей и плохо то,

+1

FR>что используется внешняя переменная, но вполне терпимо (да и улучшить тут многое можно).



Nemerle рулит

def numbers = array[5, 4, 1, 3, 9, 8, 6, 7, 2, 0];
WriteLine(numbers.Filter(_ < 5));

или так

def numbers = array[5, 4, 1, 3, 9, 8, 6, 7, 2, 0];
WriteLine($[x | x in numbers, x < 5]);

В общем, я все конечно понимаю, но до чистаты линий Ди еще прау версий нехватает. А может он так и останется на всю жизнь С++*1.5

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

C>Ну как бы... Если ты хвалишь портабельность Nemerle, то это
C>автоматически означает, что ты хвалишь Mono.

Странная логика.

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

K>Кстати, да. Правда, с 10 раз — это гипербола, а вот в 3-4 раза — вполне реально, но это только относительно объёма. Относительно удобства могу выразить субъективную оценку "в 10 раз", несмотря на то, что C#-версия насписана в VS, со всеми её достоинствами, а вот Nemerle-версия пока пишется в SciTE. Интересно, во сколько раз возрасло бы удобство, будь интеграция дописанной?

Ну, я уже пишу примерчики в интеграции. Оно конечно пока до качества шарпоской не отягивет, но уже в сто раз удобнее чем в Сцинтиле. Основной кайф в том, что ошибки замечаешь почти сразу. Часто запуск происходит с первого раза (без правок после первой компиляции). Ну, и конечно комлит с хинтами рулит неимоверно. Откровенно говоря привыкнуть к их отсуствию я так и не смог. Я конечно могу писть без них, но эффективность в разы мниже.

Что до оценок, то я скажу так. По объему кода почти на любой задаче Немерле будет в 2 раза кратче чем Шарп и в 2.5 — 3 чем С++. В некоторых случаях разница действительно может составить в 10 раз. Особенно если мерять в строках, а не килобайтах. Особо выигрышные задачи где нужно обрабатывать структуры данных (особенно иерархии), в общем там где можно применить варианты и паттерн-матчинг. Так же рулят задачи хоршо решаемые с помощю декомпозиции фукнций.

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

Опять же чтение бдует проще только если есть поддержка IDE. Иначе прийдется лазить по файлам в поисках информации о типах, а это убьет весь кайф от краткости и понятности анализируемого куска.