Re: Ой, чо с D деется-то!? - Философия программирования

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

R>Проще по объёму или по запутанности?

Запутанности у грамматике быть не может. Проблемы С++ в неоднозначностях и способах их разрешения. Другими словами проблемы С++ в семантике.

Так что по объему или по факту один черт.

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

А какие проблемы у парсеров? И где грязь?

>> понятен. И тут, пожалуй, Лисп будет полнейшим аутсайдером.
R>Тогда почему Паскаль не вытеснил всё, что можно?

А с чего бы ему это сделать? Хотя С/С++ он подвинул надо признать.

R>Даже ярые сторонники
R>синтаксиса С периодически признаются, что не умея писать на Паскаль,
R>читать его они могут.

Языки одного типа. Что тут удивительного?

R> Хотя, конечно по сравнению с
R>Lisp/Scheme/Nemerle/Scala недостаток возможностей бывает заметен. А
R>после прикручивания прозрачной кодогенерации (тоже на Паскаль,
R>разумеется, макрокод встроен в код и перегенерация происходит
R>автоматически) интуитивности не остаётся.

Знать такая реализация. Хотя хоть буей не вижу в Паскале особой интуитивности.

R>А читать LISP.. При подсветке скобок нормально. Мне хватило в школе
R>довольно малого объёма, написанного на Lisp-подобном минималистском
R>языке, чтобы это мне не мешало читать программу.

Читать Лисп не нормально. К этому конечно (как и ко всему в жизни) можно привыкнуть, но от этого код на Лиспе нормальным не становится. Даже поляки в 21 веке не используют польскую натацию.

R>Нет там грамматики ООП. ООП — всего лишь библиотека..

Дык учитывая наличие фукнции eval в Лиспе все библиотекой можно назвать. Так что не надо терминологического беспредела. Есть в стандарте — есть в языке.

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

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

R> Но если считать её
R>данностью — то грамматика весьма обширна.

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

R>Имеется много библиотек, позволяющих её вернуть при желании.

Ага. Только зачем они нужны когда яесть полноценные языки?

R> Не то,
R>чтобы ими совсем не пользовались — пользуются, когда действительно надо.
R>Потом опять бросают..

Потому что геморрой.

R>Преимуществом простота грамматики является для особо запутанных
R>макросов. Их, действительно, довольно мало. Переходить с Lisp многие не
R>хотят, скорее, из-за динамической типизации — если не считать её
R>абсолютным злом, и пользоваться при необходимости синтаксисом (после
R>небольшой привычки это не всегда удобнее), то фатальных недостатков нет,
R>и начинают играть роль мелочи — припасённая библиотека своих и найденных
R>функций, детали поведения макросистемы (вроде объявления макроса в том
R>же файле, где он используется), в случае Scheme — привычное в деталях
R>поведение полноценных continuations.

Дык зачем к чему-то привыкать когда есть алтернатива?
Лисп не принят сообществом программистов. И это уже не исправить. Никакая популяризация ему уже не поможет. Он останется уделом тех, кто готов дресировать себя и ставить мозги раком ради приемуществ которые дают макросы. Других приемуществ у Лиспа нет. Ну, а раз мы имеем альтернативу без недостатков Лиспа, но с его же достоинствами, то почему бы не поптатся ею пользоваться? Глядишь вторая попытка дойдет до мэйнстрима.

... << RSDN@Home 1.2.0 alpha rev. 637>>

VladD2 wrote:
> R>Проще по объёму или по запутанности?
>
> Запутанности у грамматике быть не может. Проблемы С++ в неоднозначностях
Ну если это не называть запутанностью, то понять логику грамматики легче
не станет.

> и способах их разрешения. Другими словами проблемы С++ в семантике.
>
> Так что по объему или по факту один черт.
>
>>> только сложность и удобство использования языка никакого отношения к
>>> сложности его грамматики не имеют. Язык удобен если он интуитивно
> R>Речь шла о проблемах парсеров, не надо грязи.
>
> А какие проблемы у парсеров? И где грязь?

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

>>> понятен. И тут, пожалуй, Лисп будет полнейшим аутсайдером.
> R>Тогда почему Паскаль не вытеснил всё, что можно?
>
> А с чего бы ему это сделать? Хотя С/С++ он подвинул надо признать.
Ну это язык, сделанный, чтобы быть читаемым. А также аккуратным и
строгим. И добавление ООП, сделанное другими людьми и по пути
наименьшего сопротивления, его не загубило. Мне вот интересно, можно ли
человеку, хорошо пишущему на разных диалектах Паскаль, но не
испорченному С (Nemerle, Haskell, Scheme, J — допускаются), объяснить,
что такое Undefined behavior и зачем это вообще может компилироваться.

> R>Даже ярые сторонники
> R>синтаксиса С периодически признаются, что не умея писать на Паскаль,
> R>читать его они могут.
>
> Языки одного типа. Что тут удивительного?
Почему-то в паре bash-perl, которые, казалось бы, тоже похожи, такого не
происходит. Ну и вообще, Паскаль, кажется, может читать программист на
любом языке.

> R> Хотя, конечно по сравнению с
> R>Lisp/Scheme/Nemerle/Scala недостаток возможностей бывает заметен. А
> R>после прикручивания прозрачной кодогенерации (тоже на Паскаль,
> R>разумеется, макрокод встроен в код и перегенерация происходит
> R>автоматически) интуитивности не остаётся.
>
> Знать такая реализация. Хотя хоть убей не вижу в Паскале особой
Ну я написал нечто за день, что я могу нормально читать и писать.
Накрутил макросов в Vim, чтобы писать с комфортом. Успокоился. Для
читаемости надо было бы обдумывать, проектировать нормально, заботиться
о недвусмысленности конструкций в потоке нормального кода...

> интуитивности.

> R>А читать LISP.. При подсветке скобок нормально. Мне хватило в школе
> R>довольно малого объёма, написанного на Lisp-подобном минималистском
> R>языке, чтобы это мне не мешало читать программу.
>
> Читать Лисп не нормально. К этому конечно (как и ко всему в жизни) можно
> привыкнуть, но от этого код на Лиспе нормальным не становится. Даже
> поляки в 21 веке не используют польскую натацию.
А какой язык читать нормально? Lisp вполне соотносится с записью
некоторых вариантов лямбда-исчисления.

> Просто классических языках вроде С и Паскаля чтобы изменить синаксис
> языка надо было менять их компиляторы, а в Лиспе и Немерле для этого
> можно определить библиотеку. Это несомненный плюс, и это удобно, но это
> не делает из языка что-то оморфное.
Ну в каком-то смысле делает. Я уже, например, привык писать в Scheme (\
x -> x) вместо (lambda (x) x) .. Как-то мне показалось, что так лучше, и
был написан макрос.

> R> Но если считать её
> R>данностью — то грамматика весьма обширна.
>
> Вот и я о том же. Так что с одной стороны в Лисе ее вообще нет, а с
> другой она не меньше чем в любом другом языке.
Обширна, но просто устроена.

> R>Имеется много библиотек, позволяющих её вернуть при желании.
>
> Ага. Только зачем они нужны когда есть полноценные языки?
Полноценные? С готовой реализацией continuations со всеми вкусностями
(за которые правда приходится платить интерпретируемостью полной
реализации Scheme)?

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

> R>Преимуществом простота грамматики является для особо запутанных
> R>макросов. Их, действительно, довольно мало. Переходить с Lisp многие не
> R>хотят, скорее, из-за динамической типизации — если не считать её
> R>абсолютным злом, и пользоваться при необходимости синтаксисом (после
> R>небольшой привычки это не всегда удобнее), то фатальных недостатков нет,
> R>и начинают играть роль мелочи — припасённая библиотека своих и найденных
> R>функций, детали поведения макросистемы (вроде объявления макроса в том
> R>же файле, где он используется), в случае Scheme — привычное в деталях
> R>поведение полноценных continuations.
>
> Дык зачем к чему-то привыкать когда есть алтернатива?
У полных continuations — нет. Редко нужно, но всё же. К тому же речь о
тех, кто уже привык. Вы пытаетесь убедить людей перейти на язык с
единственной не до конца устоявшейся реализацией, пригодной не для всех
платформ с достаточной памятью с языков семейства с десятками реализаций
— со своими недостатками и достоинствами — и многолетними традициями
(непринятость не мешает существовать заметному community).

> Лисп не принят сообществом программистов. И это уже не исправить.
> Никакая популяризация ему уже не поможет. Он останется уделом тех, кто
> готов дресировать себя и ставить мозги раком ради приемуществ которые
Да ладно. К синтаксису привыкнуть можно меньше,чем за неделю. К
чудо-библиотекам люди привыкают дольше.. Причём в любом языке.

> дают макросы. Других приемуществ у Лиспа нет. Ну, а раз мы имеем
> альтернативу без недостатков Лиспа, но с его же достоинствами, то почему
> бы не поптатся ею пользоваться? Глядишь вторая попытка дойдет до мэйнстрима.
Вы меряете пропаганду Nemerle своим примером. У Вас не было ничего, в
чём есть нормальные макросы, и Вы работали на платформе .NET . Я
полностью согласен, что все, для кого .NET можно считать единственной
используемой платформой и кто никогда не пользовался теми вещами,
которых в Nemerle нет, выиграют от использования Nemerle. Вы же
занимаетесь перевербовкой. Ответ на вопрос "Почему не Nemerle?" для меня
прост — Scheme довольно мощна и стоит у меня и на ноутбуке, и на КПК, а
Nemerle на КПК не встанет, причём мне придётся — в виде бонуса —
переучивать названия стандартных ФВП (сейчас у меня имеется небольшая
библиотечка тех, которые мне нужны поверх Pocket Scheme. Ясно, что на
guile тоже работают. Одна из них использует извращение, которое на
Nemerle будет выглядеть уродливо; она, конечно, сама — извращённый
эксперимент, но обидно).

Posted via RSDN NNTP Server 2.1 beta

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

R>Ну это язык, сделанный, чтобы быть читаемым. А также аккуратным и
R>строгим. И добавление ООП, сделанное другими людьми и по пути
R>наименьшего сопротивления, его не загубило. Мне вот интересно, можно ли
R>человеку, хорошо пишущему на разных диалектах Паскаль, но не
R>испорченному С (Nemerle, Haskell, Scheme, J — допускаются), объяснить,
R>что такое Undefined behavior и зачем это вообще может компилироваться.

Юморист. UB в Паскале было сколько угодно. Возврати указатель на локальную переменную из процедуры и получи UB. А вот Nemerle и Haskell, действительно, UB нет by design.

... << RSDN@Home 1.2.0 alpha rev. 637>>

VladD2 wrote:
> R>Ну это язык, сделанный, чтобы быть читаемым. А также аккуратным и
> R>строгим. И добавление ООП, сделанное другими людьми и по пути
> R>наименьшего сопротивления, его не загубило. Мне вот интересно, можно ли
> R>человеку, хорошо пишущему на разных диалектах Паскаль, но не
> R>испорченному С (Nemerle, Haskell, Scheme, J — допускаются), объяснить,
> R>что такое Undefined behavior и зачем это вообще может компилироваться.
>
> Юморист. UB в Паскале было сколько угодно. Возврати указатель на
> локальную переменную из процедуры и получи UB. А вот Nemerle и Haskell,
> действительно, UB нет by design.
Это всё же Access Violation. Это свойство памяти в run-time. Это вещь
общая для всех языков с возможностью игр с указателями. Что происходит,
понять можно. Такой эффект моделируется на ассемблере, если угодно. Даже
в некоторых Scheme, есть отдалённый аналог такого действия, правда, он
приведёт к понятному exception (ну, можно явно потребовать создать
структуру, допускающую GC своих элементов, и обратиться к элементу без
проверки, что его ещё не собрали). А вот что такое "++i = i++ + ++i;"
понять можно только изнутри всей С-шной системы синтаксиса. Остальные
поймут только заключение — "в общем, это извращение и так делать не
надо". Также как и глубокую идею, исходя из которой "if(a<b);" является
законным выражением.

Posted via RSDN NNTP Server 2.1 beta

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

>> Юморист. UB в Паскале было сколько угодно. Возврати указатель на
>> локальную переменную из процедуры и получи UB. А вот Nemerle и Haskell,
>> действительно, UB нет by design.
R>Это всё же Access Violation.

Не-а. Это чистое UB. Все будет зависеть от того как биты в стэке лягут.

R> Это свойство памяти в run-time. Это вещь
R>общая для всех языков с возможностью игр с указателями.

Отнюдь. Насколько я знаю в Обероне таких проблем нет.

... << RSDN@Home 1.2.0 alpha rev. 637>>

VladD2 wrote:
>>> Юморист. UB в Паскале было сколько угодно. Возврати указатель на
>>> локальную переменную из процедуры и получи UB. А вот Nemerle и Haskell,
>>> действительно, UB нет by design.
> R>Это всё же Access Violation.
> Не-а. Это чистое UB. Все будет зависеть от того как биты в стэке лягут.
При других непойманных проходах по памяти тоже может всё зависеть от
расклада. Я имел в виду AV как вид ошибки. То, что здесь конкретно она
не детектируется как таковая — неудача, но не отменяет того, что ошибка
вида ссылки на освобождённую память. А не вида "и как это поймёт
компилятор".

> R> Это свойство памяти в run-time. Это вещь
> R>общая для всех языков с возможностью игр с указателями.
>
> Отнюдь. Насколько я знаю в Обероне таких проблем нет.
Там нет возможности игр — только очень чётко регламентированные вещи,
поэтому динамический массив в библиотеке. Не то, чтобы это было особо плохо.

Posted via RSDN NNTP Server 2.1 beta

Свежие вести с полей

Вышел D v.1.005, в котором появились очень интересные штуки: MixinStatements, MixinExpressions и MixinDeclarations.
Примеры MixinStatements из документации:

void main()
{
    int j;
    mixin("
    int x = 3;
    for (int i = 0; i < 3; i++)
        writefln(x + i, ++j);
    ");    // ok

    const char[] s = "int y;";
    mixin(s);  // ok
    y = 4;     // ok, mixin declared y

    char[] t = "y = 3;";
    mixin(t);  // error, t is not evaluatable at compile time

    mixin("y =") 4; // error, string must be complete statement

    mixin("y =" ~ "4;");  // ok
}

А это пример MixinExpression:

int foo(int x)
{
    return mixin("x + 1") * 7;  // same as ((x + 1) * 7)
}

Так же появились ImportExpression:

void foo()
{
    // Prints contents of file foo.txt
    writefln( import("foo.txt") );
}

Вот что по этому поводу в списке рассылки digitalmars.D.announce сказал Вальтер Брайт:

Kevin Bealer>It looks like one could write a few hundred line module that can pull in and do compile-time interpreting of a language of the complexity of say, Scheme. And the code in the module could be both readable and straightforward... And the results would be absorbed into the calling code as normal optimizable statements...

Walter Bright> The irony is that it only took 3 hours to implement, which shows the power of having the lexing, parsing, and semantic passes be logically distinct.

The idea is to enable the creation of DSLs (Domain Specific Languages) that don't have the crippling problem C++ expression templates have — that of being stuck with C++ operators and precedence.

To make this work, however, one must be able to manipulate strings at compile time. I've made a start on a library to do this, std.metastrings, based on earlier work by Don Clugston and Eric Anderton.

This is just the start of what's going to happen with D 2.0.

Kevin Bealer>Выглядит так, как будто можно написать несколько модуль из нескольких сотен строк который можно подключить и над которым выполнится интерпритация времени компиляции и все это на языке со сложностью, скажем, Scheme. И код в модуле будет и читаемым и простой... И результаты будут встроены в вызываемый код как нормальные, поддающиеся оптимизации выражения...

Walter Bright> Ирония в том, что реализация заняла всего три часа, что показывает мощь того, что лексический, синтаксический и семантический анализ логически разделены.

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

Тем не менее, чтобы это работало, необходимо уметь манипулировать строками во время компиляции. Я начал делать библиотеку для этого, std.metastrings, базирующуюся на предыдущих работах Don Clugston и Eric Anderton.

И это только начало того, что произойдет в D 2.0.

Уж действительно, чой-то с D деется!

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

VD>

Юморист. UB в Паскале было сколько угодно. Возврати указатель на локальную переменную из процедуры и получи UB.

В Паскале невозможно было возвратить указатель на локальную переменную. Но без UB не было счастья программистского. Поэтому появился Турбо-Паскаль.

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

E>Свежие вести с полей

E>Уж действительно, чой-то с D деется!

Угу, очень интересно куда в конце концов кривая вывезет

Кто нибудь сможет предсказать как будет выглядеть D 3.0?

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

VD>>

Юморист. UB в Паскале было сколько угодно. Возврати указатель на локальную переменную из процедуры и получи UB.

Т>В Паскале невозможно было возвратить указатель на локальную переменную. Но без UB не было счастья программистского. Поэтому появился Турбо-Паскаль.

И не говори

. Вот что на собеседовании спрашивать у человека по языку где даже нет UB

.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

Т>В Паскале невозможно было возвратить указатель на локальную переменную. Но без UB не было счастья программистского. Поэтому появился Турбо-Паскаль.

Исходный Паскль я не видел. Но вроде бы Вирт писал, про указатели. А раз они были, то явно можно было получить и UB. Это только в Обероне он все привел в логический порядок.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

E>Уж действительно, чой-то с D деется!

Да на этом уже можно много чего наворотить, в общем текстовая compile time кодогенерация, я вроде нигде пока такого не видел

Попробовал для тренировки переделать вот этот Re[44]: Как скрестить ужа и ежа или статическую и утиные тип пример, получается компактнее и лучше и без внешних переменных:

import std.stdio;

template from(alias vA, char [] var)
{   
    alias  typeof(vA[0]) T;

    template where(char [] cond)
    {
        T[] select(char[] execs)()
        {
            T[] result;
            foreach(v; vA)
            {
                mixin(var ~ "= v;");
                if(mixin(cond)) 
                {
                    result ~= [mixin(execs)];
                }    
            }
            return result;
        }
    }
}


void main()
{
    auto numbers = [5, 4, 1, 3, 9, 8, 6, 7, 2, 0];

    writefln(numbers);
    writefln();
    
    auto f = from!(numbers, "int x")
                .where!("x < 5")
                .select!("x + 1");
    
    writefln(f);
    
    auto f2 = from!(numbers, "int y")
                .where!("y % 2 == 1")
                .select!("y");
    
    writefln(f2);
    
}

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

FR>Да на этом уже можно много чего наворотить, в общем текстовая compile time кодогенерация, я вроде нигде пока такого не видел

FR>Попробовал для тренировки переделать вот этот Re[44]: Как скрестить ужа и ежа или статическую и утиные тип пример, получается компактнее и лучше и без внешних переменных:

В обсуждениях Вальтер Брайт пока говорит, что по его мнению, в текстовых mixin-ах нежелательно использовать D-шный код. Мол, они были придуманы для того, чтобы

a) импортировать в программу двоичные ресурсы (иконки, к примеру) во время компиляции;
b) парсить и обрабатывать в compile-time внешние DSL, которые не являются D-шным кодом.

В связи с этим я ему задал вопрос о том, какие же DSL он в этом случае имеет в виду и что будет, если DSL-ли будут не самыми тривиальными. Посмотрим, что ответит.

Лично мне кажется, что для поддержки серьезных DSL с отличным от D синтаксисом необходимо делать стадийную обработку исходного кода в процессе компиляции. Чтобы обработка текстовых mixin-ов осуществлялась не шаблонами в compile time, а обычным D-шным кодом со всей присущей ему мощностью. На одних static if-ах и рекурсивных шаблонах, имхо, далеко не уедешь.

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

E>В обсуждениях Вальтер Брайт пока говорит, что по его мнению, в текстовых mixin-ах нежелательно использовать D-шный код. Мол, они были придуманы для того, чтобы

E>a) импортировать в программу двоичные ресурсы (иконки, к примеру) во время компиляции;
E>b) парсить и обрабатывать в compile-time внешние DSL, которые не являются D-шным кодом.

Вот как раз парсить и обрабатывать станет значительно легче если использовать именно строки с D'шным кодом.

E>В связи с этим я ему задал вопрос о том, какие же DSL он в этом случае имеет в виду и что будет, если DSL-ли будут не самыми тривиальными. Посмотрим, что ответит.

Да интересно.

E>Лично мне кажется, что для поддержки серьезных DSL с отличным от D синтаксисом необходимо делать стадийную обработку исходного кода в процессе компиляции. Чтобы обработка текстовых mixin-ов осуществлялась не шаблонами в compile time, а обычным D-шным кодом со всей присущей ему мощностью. На одних static if-ах и рекурсивных шаблонах, имхо, далеко не уедешь.

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

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

E>b) парсить и обрабатывать в compile-time внешние DSL, которые не являются D-шным кодом.

А если DSL не совсем внешние, и частично состоят из D кода? Например мне уже понятно что примерно такое:

auto func = lambda!("x -> x + 123", int);

auto rez = lambda!("x, y -> x - y")(1, 3);

вполне реально уже сделать, но довольно трудоемко так как нет библиотек для метапарсинга строк.

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

E>>b) парсить и обрабатывать в compile-time внешние DSL, которые не являются D-шным кодом.

FR>А если DSL не совсем внешние, и частично состоят из D кода? Например мне уже понятно что примерно такое:

FR>

FR>auto func = lambda!("x -> x + 123", int);

FR>auto rez = lambda!("x, y -> x - y")(1, 3);
FR>

FR>вполне реально уже сделать, но довольно трудоемко так как нет библиотек для метапарсинга строк.

Что-то мне кажется, что это не есть правильно. Такие базовые вещи, как лямбды, должны быть частью языка. И пытаться имитировать их через строковые mixin-ы -- не правильно. Тем более, что в таких случаях мы лишаемся возможной поддержки IDE (для тех, кому это нужно).

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

E>Что-то мне кажется, что это не есть правильно. Такие базовые вещи, как лямбды, должны быть частью языка. И пытаться имитировать их через строковые mixin-ы -- не правильно. Тем более, что в таких случаях мы лишаемся возможной поддержки IDE (для тех, кому это нужно).

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

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

E>Что-то мне кажется, что это не есть правильно. Такие базовые вещи, как лямбды, должны быть частью языка. И пытаться имитировать их через строковые mixin-ы -- не правильно. Тем более, что в таких случаях мы лишаемся возможной поддержки IDE (для тех, кому это нужно).

Насчет IDE почему лишаемся? Все же в compile time.
Еще эти миксины неплохо бы переделать чтобы то что в них передается было как-то без обычных строковых кавычек

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

E>>Что-то мне кажется, что это не есть правильно. Такие базовые вещи, как лямбды, должны быть частью языка. И пытаться имитировать их через строковые mixin-ы -- не правильно. Тем более, что в таких случаях мы лишаемся возможной поддержки IDE (для тех, кому это нужно).

FR>Насчет IDE почему лишаемся? Все же в compile time.

Ну потому, что когда ты тыкаешь мышкой в строковый литерал:

auto func = lambda!("x -> x + 123", int);

и попадаешь, к примеру, на символ x, то IDE должна сообразить, что это не простой строковый литерал, а часть mixin-а. Затем попытаться его раскрыть (вызвав фоновую компиляцию), затем попробовать отыскать этот символ x в том, что получилось и только после этого выдать информацию о нем

FR>Еще эти миксины неплохо бы переделать чтобы то что в них передается было как-то без обычных строковых кавычек

Можно же использовать WYSIWYG литералы:

auto func = lambda!(`x -> x + 123`, int);

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

E>>Что-то мне кажется, что это не есть правильно. Такие базовые вещи, как лямбды, должны быть частью языка. И пытаться имитировать их через строковые mixin-ы -- не правильно. Тем более, что в таких случаях мы лишаемся возможной поддержки IDE (для тех, кому это нужно).

FR>Я не имел в виду именно лямбды, а хотел показать что в таких DSL удобно частично использовать именно D'шный код, например зачем писать парсеры выражений для правой части этой же лямбды, когда можно просто подставить миксином.

В оригинале Брайт сказал, дословно, следующее:

2) import code that's in DSL (Domain Specific Language), not D, form.

т.е. главной мыслью, на мой взгляд, было то, что строковые mixin и import не должны быть заменой C-шного include.

От:	VladD2	www.nemerle.org
Дата:	27.01.07 15:24
Оценка:

	От:	raskin
	Дата:	27.01.07 18:12
	Оценка:	+2

От:	VladD2	www.nemerle.org
Дата:	27.01.07 18:38
Оценка:

	От:	raskin
	Дата:	27.01.07 18:49
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	27.01.07 19:32
Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	06.02.07 09:13
Оценка:	43 (4)

	От:	Андрей Хропов
	Дата:	06.02.07 20:07
	Оценка:

	От:	FR
	Дата:	07.02.07 12:37
	Оценка:	23 (3)