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

VD>Я конечно могу обяснить в чем разница между текстукльными макросами и модификацией АСТ на базе квази-цитирования. Но это уже сто раз обсуждалось. Не проще ли сделать поиск?

Я понимаю в чем разница, вопрос не в этом. Немерле появился сравнительно недавно, си-шарп — уже сравнительно давно. Ты мне веришь, что я могу использовать текстовые макросы только на благо, так сказать, отечества? Когда разрабатывали си-шарп, текстовые макросы решили убрать, хотя мы и потеряли вместе с ними дополнительные возможности. Еще раз — я не сравниваю макросы немерле и макросы С. Я понимаю, в чем недостатки макросов С и чем макросы немерле лучше. Но при этом макросы С тоже могут быть очень удобны и полезны, особенно если — вернемся годика этак на 3 назад, прям в 5ый класс — никакой реальной работающей альтернативы им нет. А теперь собственно вопрос — как ты думаешь, почему сишных макросов все-таки нет в си-шарпе?

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

IT>RFD используется в самых что ни на есть типичных бизнес приложениях.

Подмену понятие чувствуешь?
Алгоритмы архивирования, кодирования и прочая з@@@@стая муть тоже используются "в самых что ни на есть типичных бизнес приложениях" но сами они от этого таковыми не становятся.

IT>Причём подход, используемый в BLToolkit/RFD способен навсегда закрыть тему DAL и свести разработку этого лэйера к декларативному описанию. Причём к декларативному описанию не в XML или других чуждых форматах, а непосредственно в терминах языка разработки приложения, что позволяет гибко совмещать декларативноть с императивными расширениями.

Скажи, а как ты видишь реализацию РФД на немерле когда весь бизнес-код на си-шарпе?

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

IT>>RFD используется в самых что ни на есть типичных бизнес приложениях.

ВВ>Подмену понятие чувствуешь?

Какой смысл мне что-то подменять? Может я не чувствую смысла в твоём вопросе?

ВВ>Скажи, а как ты видишь реализацию РФД на немерле когда весь бизнес-код на си-шарпе?

Для того, чтобы использовать RFD из немерле, RFD на немерле переписывать не надо. Так же как и не надо переписывать весь фреймворк. Для устранения проблем run-time генерации нужно написать несколько макросов, которые потом и использовать из приложений, написанных на немерле. Первым делом я бы начал писать на немерле именно те вещи, которые сейчас генерируются в run-time — это тот самый DAL и ObjectModel. Причём, если с первым всё понятно, то со второй я даже не представляю сколько можно нафантазировать.

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

VD>Кстати, а кто мешает используя один макрос создать еще одни оберточный? Ну, мало ли пересеклись у нас имена. Ну, создам обертку для чужого макроса.

Гениально. Как только я до этого не додумался? Nemerle это действительно позволяет — вот и ответ на вопрос о конфликтующих расширениях.

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

BB>Так что есть подозрение что это не окажет решающей роли. А решающую роль как обычно может сыграть бОльшая простота языка с сохранением хороших возможностей, более высокая дуракоустойчивость... — в общем все то, благодаря чему си-шарп "лучше" С++. А вот как у Немерле с этим?

Дуракоустойчивость очень высокая. Nemerle вообще как цербер, вытряхивает всю душу разработчика еще на этапе компиляции. Даже зачастую не только указывает на ошибку, но и подсказывает что делать(особенно при написании макросов). Это вообще такая фирменная фишка, в других компиляторах я такого практически никогда не видел. Выводит также очень много разных ворнингов, значительно больше чем в C#. Поэтому скомпилированный без предупреждений и ошибок код обычно работает сразу. В добавок ко всему Nemerle часто вставляет собственные проверки исключительных ситуаций. Например match, продвинутый аналог switch-case, обычно заканчивается исключением если ни один из вариантов не прошел и дефолтного варианта нет(он в этом случае еще и предупреждение при компиляции выдает). Так что у Nemerle компилятор очень строгий и вольностей не любит.

А вот о простоте сложно судить. В ряде случаев язык проще C#, в ряде других такой же, а местами гораздо сложнее. Разработчики пропагандируют совсем другой стиль разработки. Именно поэтому например макросы break, continue и return запрятаны в Nemerle.Imperative. По умолчанию все поля иммутабельные. Для переменных и изменяемых полей используется ключевое слово mutable. В некоторых задачах такой подход дает преимущество, в других не дает.

К тому же надо учитывать, что Nemerle это надмножество C#, т.е. он и без макросов предоставляет большее количество возможностей. Многое просто не с чем сравнить в C#. Естественно, что чем больше возможностей тем больше времени нужно чтобы полностью их изучить. Для человека знающего только языки вроде C# и Java это будет довольно трудно. Для человека знающего хоть один функциональный язык(или другой язык с паттерн-мэтчингом и смежными возможностями, например Prolog) это будет намного проще. Для человека хорошо знающего и C#, и например один из языков семейства ML(я кстати ML знаю только чуть-чуть ) это будет тривиальной задачей.

Должен отметить, что по субъективным ощущениям код получается более читабельным и значительно короче чем на C#. Я думаю Nemerle вообще легко изучать по примерам.

Так что и "простоту" необходимо сравнивать именно на конкретных примерах, причем я считаю что лучше на обычном коде без макросов и прочих наворотов(и здесь Nemerle тоже дает фору C#).Интересного и жизнеспособного примера я придумать не смог(предлагайте свои идеи), но вот один нежизнеспособный, но поучительный мое больное воображение выдало. Конечно это образец плохого дизайна и вообще так писать код не стоит(например используется хардкодинг и публичные поля), но он наглядно демонстрирует некоторые отличия между Nemerle и C#.(Это я к тому, что не надо говорить как можно этот пример оптимизировать и улучшить, я скорее всего в курсе.) Цель примера не в решении какой-то задачи, а в демонстрации различия синтаксиса и возможностей. Пример одинаково неоптимален на обоих языках, так что все по честному.

Пример я сначала написал на Nemerle, а затем перевел на C#. При этом функциональность не идентична. Так JunkFood в Nemerle сделан вариантом, а не перечислением. Использование перечисления сделало бы код даже более кратким, но менее расширяемым(к варианту достаточно легко можно добавить различные свойства и методы). Еще в C# версии вместо списков массивы, но заменить списки массивами в Nemerle очень легко(размер програмы увеличится незначительно, просто со списками чуть-чуть красивее). А так програмы выдают в консоль один и тот же текст. По идее по коду должно быть достаточно легко понятно, что он делает. Но если что непонятно — спрашивайте.

Сначала код на C#(133 строки, 3181 символ):

using System;

enum JunkFood
{
    Hotdog,
    Hamburger,
    Cheeseburger,
    Chips,
    CocaCola
}

enum Currency
{
    USD,
    EUR,
    RUB
}

struct Price
{
    public double amount;
    public Currency currency;

    public Price(double amount, Currency currency)
    {
        this.amount = amount;
        this.currency = currency;
    }

    public Price ConvertTo(Currency otherCurrency)
    {
        // no conversion required
        if (currency == otherCurrency)
            return this;
        switch(otherCurrency)
        {
            case Currency.USD:
                if (currency == Currency.EUR)
                    return new Price(amount * 1.188, Currency.USD);
                else
                if (currency == Currency.RUB)
                    return new Price(amount / 28.22, Currency.USD);
            break;
            case Currency.RUB:
                if (currency == Currency.USD)
                    return new Price(amount * 28.22, Currency.RUB);
                else
                if (currency == Currency.EUR)
                    return new Price(amount * 33.52, Currency.RUB);
            break;
            case Currency.EUR:
                if (currency == Currency.USD)
                    return new Price(amount / 1.188, Currency.EUR);
                else
                if (currency == Currency.RUB)
                    return new Price(amount / 33.52, Currency.EUR);
            break;

        }
        throw new Exception("Convertion from " + currency.ToString() 
                + " to " + otherCurrency.ToString() + " not supported!");
    }

    public override string ToString()
    {
        string priceStr = amount.ToString();
        switch(currency)
        {
            case Currency.USD:
                 priceStr = "$" + priceStr;
            break;
            case Currency.RUB:
                priceStr = priceStr + " Rub.";
            break;
            case Currency.EUR:
                priceStr = priceStr + " Euro";
            break;
            default:
                throw new Exception("Invalid currency code: " + currency.ToString());
        }
        return priceStr;
    }
}

class JunkPrice
{
    public JunkPrice(JunkFood junk, Price price)
    {
        this.junk = junk;
        this.price = price;
    }
    public JunkFood junk;
    public Price price;
}

class Test
{
    delegate JunkPrice JunkPriceConvertor(JunkPrice junk);
    public static void Main()
    {
        JunkPrice[] prices =
            new JunkPrice[]
                 {
                     new JunkPrice(JunkFood.Hotdog,       new Price(0.4, Currency.EUR)),
                     new JunkPrice(JunkFood.Hamburger,    new Price(1.3, Currency.USD)),
                     new JunkPrice(JunkFood.Cheeseburger, new Price(38 , Currency.RUB)),
                     new JunkPrice(JunkFood.Chips,        new Price(0.3, Currency.EUR)),
                     new JunkPrice(JunkFood.CocaCola,     new Price(0.5, Currency.USD))
                 };

        foreach(JunkPrice junk in prices)
            Console.WriteLine("(\"{0}\", {1})", junk.junk, junk.price);

        Console.WriteLine("-------------------");

        JunkPrice[] rubPrices =
            Array.ConvertAll<JunkPrice,JunkPrice>(prices, 
            delegate(JunkPrice junk)
            {
                return new JunkPrice(junk.junk, junk.price.ConvertTo(Currency.RUB));
            });
        foreach(JunkPrice junk in rubPrices)
            Console.WriteLine("(\"{0}\", {1})", junk.junk, junk.price);
        try
        {
            Price intentionalFailure = new Price(0.5, (Currency) 55);
            intentionalFailure = intentionalFailure.ConvertTo((Currency) 32);
        }
        catch(Exception ex)
        {
            Console.WriteLine(ex.ToString());
        }
    }
}

Теперь Nemerle(93 строки, 2220 символов, ~ в 1.4 раза меньше по обоим параметрам):

using System;

variant JunkFood
{
    | Hotdog
    | Hamburger
    | Cheeseburger
    | Chips
    | CocaCola
    public override ToString() : string
    {
        match(this)
        {
            | Hotdog => "\"Hotdog\""
            | Hamburger => "\"Hamburger\""
            | Cheeseburger => "\"Cheeseburger\""
            | Chips => "\"Chips\""
            | CocaCola => "\"CocaCola\""
        }
    }
}

enum Currency
{
    | USD
    | EUR
    | RUB
}

[Record]
struct Price
{
    public amount : double;
    public currency : Currency;
    public ConvertTo(otherCurrency : Currency) : Price
    {
        match((otherCurrency, currency))
        {
            // no convertion required
            | (_, _) when (otherCurrency == currency) => this
            | (USD, EUR) => Price(amount * 1.188, Currency.USD)
            | (USD, RUB) => Price(amount / 28.22, Currency.USD)
            | (RUB, USD) => Price(amount * 28.22, Currency.RUB)
            | (RUB, EUR) => Price(amount * 33.52, Currency.RUB)
            | (EUR, USD) => Price(amount / 1.188, Currency.EUR)
            | (EUR, RUB) => Price(amount / 33.52, Currency.EUR)
            | _ => throw Exception($"Convertion from $currency to $otherCurrency not supported!")
        }
    }

    public override ToString() : string
    {
        match(currency)
        {
            | USD => $"$$$amount"
            | RUB => $"$amount Rub."
            | EUR => $"$amount Euro"
            | _   => throw Exception($"Invalid currency code $currency")
        }
    }
}

module Main
{
    Main() : void
    {
        def prices = [(JunkFood.Hotdog(),       Price(0.4, Currency.EUR)),
                      (JunkFood.Hamburger(),    Price(1.3, Currency.USD)),
                      (JunkFood.Cheeseburger(), Price(38,  Currency.RUB)),
                      (JunkFood.Chips(),        Price(0.3, Currency.EUR)),
                      (JunkFood.CocaCola(),     Price(0.5, Currency.USD))];

        foreach(junk in prices)
            Console.WriteLine(junk.ToString());

        def rubPrices =
            prices.Map(fun(junk, price) { (junk, price.ConvertTo(Currency.RUB)) });

        Console.WriteLine("-------------------");

        foreach(junk in rubPrices)
            System.Console.WriteLine(junk.ToString());
        try
        {
            mutable intentionalFailure = Price(0.5, 55 :> Currency);
            intentionalFailure = intentionalFailure.ConvertTo(32 :> Currency);
        }
        catch
        {
            | ex => Console.WriteLine(ex.ToString());
        }
    }
}

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

IT>Для того, чтобы использовать RFD из немерле, RFD на немерле переписывать не надо. Так же как и не надо переписывать весь фреймворк. Для устранения проблем run-time генерации нужно написать несколько макросов, которые потом и использовать из приложений, написанных на немерле. Первым делом я бы начал писать на немерле именно те вещи, которые сейчас генерируются в run-time — это тот самый DAL и ObjectModel. Причём, если с первым всё понятно, то со второй я даже не представляю сколько можно нафантазировать.

Ключевые слова выделены

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

VD>>>Да она сама в Лиспе под большим вопросом. Язык то по сути динамически типизированный. Ну, как ты сможешь определить что некий парамерт это получает INT если в него передано сложное выражение?
Y>>(declare (type integer arg)) ?

VD>У макроса тип параметра не может быть integer. У него тип параметра должен быть "векта АСТ". Для Лиспа это будет означать S-выражение.
VD>Так вот из этого S-выражения нужно иметь возможность вычислить тип передаваемого выражения. Причем, даже если типы не были указаны явно.
VD>Насколько мне извесно — это невозможно.

(defmacro mymacro (a)
(declare (type integer a))
`(print ,a))
=> MYMACRO
(mymacro "1")
=> exception raised
(mymacro 1)
=>

1
1

это плод моих галлюцинаций?

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

IT>>Для того, чтобы использовать RFD из немерле, RFD на немерле переписывать не надо. Так же как и не надо переписывать весь фреймворк. Для устранения проблем run-time генерации нужно написать несколько макросов, которые потом и использовать из приложений, написанных на немерле. Первым делом я бы начал писать на немерле именно те вещи, которые сейчас генерируются в run-time — это тот самый DAL и ObjectModel. Причём, если с первым всё понятно, то со второй я даже не представляю сколько можно нафантазировать.

ВВ>Ключевые слова выделены

Я правда не понимаю что ты хочешь этим сказать.

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

IT>Я правда не понимаю что ты хочешь этим сказать.

Вот сейчас я положим пишу на выбенет а си-шарп не знаю — есть у меня какие-то проблемы при использовании РФД? Думаю, что нет. А если переписать все это добро используя мощные компайл-тайм фичи немерле? Фактически мы начинаем терять ту возможность, о который ты сам только что писал — возможность легко _совмещать_ языки.

Заметил пару вещей, которые можно было бы улучшить.

VK>| (_, _) when (otherCurrency == currency) => this

| _ when (otherCurrency == currency) => this

VK>prices.Map(fun(junk, price) { (junk, price.ConvertTo(Currency.RUB)) });

// так возможно будет понятнее
prices.Map(fun((junk, price)) { (junk, price.ConvertTo(Currency.RUB)) });[/

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

IT>>Я правда не понимаю что ты хочешь этим сказать.

ВВ>Вот сейчас я положим пишу на выбенет а си-шарп не знаю — есть у меня какие-то проблемы при использовании РФД? Думаю, что нет. А если переписать все это добро используя мощные компайл-тайм фичи немерле? Фактически мы начинаем терять ту возможность, о который ты сам только что писал — возможность легко _совмещать_ языки.

Ты имеешь ввиду что нельзя будет использовать макросы Немерле из других языков? Ну так это ясный перец. Но результаты работы этих макросов использовать вполне можно будет. Тот же RFD можно доработать таким образом, что он будет либо сам продолжать генерировать необходимые вещи, либо подхватывать то, что сгенерировано Nemerle.

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

VK>

VK>// так возможно будет понятнее
VK>prices.Map(fun((junk, price)) { (junk, price.ConvertTo(Currency.RUB)) });[/
VK>

Ты погоди.. Я пока еще твой предыдущий пост не дочитал

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

Y>это плод моих галлюцинаций?

Это плод твоего непонимания.

Речь не о типизации перменных в макросе, а о получении информации о типах передаваемых выражений.

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

Y>>это плод моих галлюцинаций?

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

Подождите, подождите. О каких переменных Вы толкуете?

"(defmacro mymacro (a)
(declare (type integer a))
`(print ,a))"

Чем Вам A не параметр? Мне передан параметр A, я потребовал, чтобы он был INTEGER. Хотите узнавать а не требовать? TYPE-OF/CLASS-OF к Вашим услугам. Ы?

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

VD>Кстати, а кто мешает используя один макрос создать еще одни оберточный? Ну, мало ли пересеклись у нас имена. Ну, создам обертку для чужого макроса.

Зашибись. Клиент покупает навороченную либу у одного поставщика за N килобаксов, затем у другого за M килобаксов. А затем еще тратит свое время на написание оберток для конфликтующих макросов. И следит за тем, чтобы LifeStyle не заканчивались. Хотя единственное желание у клиента, потратившего N+M собственных денежков, чтобы траха вообще не было.

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

E>Зашибись. Клиент покупает навороченную либу у одного поставщика за N килобаксов, затем у другого за M килобаксов. А затем еще тратит свое время на написание оберток для конфликтующих макросов. И следит за тем, чтобы LifeStyle не заканчивались. Хотя единственное желание у клиента, потратившего N+M собственных денежков, чтобы траха вообще не было.

А в плюсах не так, что ли?

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

use macrolib AAA
{
    // do some stuff
};

use macrolib BBB
{
    // do another stuff
};

Есть еще идеи?

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

E>Зашибись. Клиент покупает навороченную либу у одного поставщика за N килобаксов, затем у другого за M килобаксов. А затем еще тратит свое время на написание оберток для конфликтующих макросов. И следит за тем, чтобы LifeStyle не заканчивались. Хотя единственное желание у клиента, потратившего N+M собственных денежков, чтобы траха вообще не было.

Это уже откровенные придирки. Решить обозначенную тобой проблему предложенным Владом способом — дело получаса. Фактически речь идёт о рапере. Ты разве никогда не писал раперов для купленных за N килобаксов либ? Не смеши нас, пожалуйста

E>Зашибись. Клиент покупает навороченную либу у одного поставщика за N килобаксов, затем у другого за M килобаксов. А затем еще тратит свое время на написание оберток для конфликтующих макросов. И следит за тем, чтобы LifeStyle не заканчивались. Хотя единственное желание у клиента, потратившего N+M собственных денежков, чтобы траха вообще не было.

Ты видимо никогда не был клиентом(или плохо знаком с этим зверьком) и поэтому не совсем разбираешься в том как это работает. Если для "клиента" проблема написать макрос-обертку или ему вообще не пришла в голову эта идея, то он обычно трезвонит в саппорт компаний-поставщиков, чтобы они оправдали потраченные (N+M+1) килобаксов и исправили проблему(ну или накрайняк подсказали, причем желательно в виде работающего кода, бескомпромиссное решение проблемы).

Я вот имел счастье наблюдать за тем как ведут себя клиенты, купившие либу всего лишь за (N+1) сотен баксов. Ведут они себя мягко говоря нагло, так как клиент всегда прав. Не думаю, что в случае больших сум будет иначе. Вообще хороший саппорт это залог успеха, даже если количество потенциальных проблем в продукте достаточно велико.

P.S. И вообще раз уж ты объявил, что сделаешь перерыв на год в обсуждении Nemerle, то уж будь добр потверждай свои слова(или опровергай). Есть куда более интересные темы для разговоров, чем проблемы высосанные из пальца.

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

VK>Ты видимо никогда не был клиентом(или плохо знаком с этим зверьком) и поэтому не совсем разбираешься в том как это работает. Если для "клиента" проблема написать макрос-обертку или ему вообще не пришла в голову эта идея, то он обычно трезвонит в саппорт компаний-поставщиков, чтобы они оправдали потраченные (N+M+1) килобаксов и исправили проблему(ну или накрайняк подсказали, причем желательно в виде работающего кода, бескомпромиссное решение проблемы).

Я так понимаю, что до сих пор конфликты между либами от различных производителей на уровне синтаксиса языка были большой редкостью.

E>Я так понимаю, что до сих пор конфликты между либами от различных производителей на уровне синтаксиса языка были большой редкостью.
На уровне синтаксиса может и не было. А вот на уровне семантики скорее всего были. Насколько мне известно раньше на C++ коммерческие библиотеки шаблонов были очень распространенным явлением(начало-середина 90х, да и сейчас вроде какие-то остались). Уверен, что проблема совместимости разных библиотек присутствовала.

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