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

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

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

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

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

Вообще то вся информация что это часть миксина у комилятора (и наверно у парсера IDE тоже) есть
Хотя согласен IDE конечно не сможет понять смысл твоего DSL.

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

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

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

Спасибо, вертелось же в голове, что есть нечто подобное, но амнезия победила

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

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

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

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

В смысле макросов и include? Или вообще для метапрограмирования?
Ну мало ли чего он хочет, Страуструпу наверно и в страшных кошмарах не могло приснится как над шаблонами будут извращатся

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

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

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

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

FR>В смысле макросов и include? Или вообще для метапрограмирования?

Я еще сам не понял, какое же мнение у Брайта по поводу роли строковых mixin-ов. Нужно подождать, пока все проясниться. Тем более, что у меня складывается впечатление, что это еще далеко не все, что грядет в D. Сегодня Александреску обмолвился, что в D через несколько месяцев грядет какая-то макросистема.

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

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

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

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

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

Есои это приведет к нечто похожему на Nemerle будет версия Nemerle без вируальной машины

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

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

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

<skip>

Осталось только добавить классы для генерации кода из синтаксического дерева и будет счастье
Мне вот непонятно теперь в чем преимущества Template Mixin если они легко эмулируются через Mixin Expression:

class A(T)
{
 static const char[] v = "int a;";
 mixin(v);
}

Или так нельзя ?
Если нельзя то почему ?

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

__><skip>

__>Осталось только добавить классы для генерации кода из синтаксического дерева и будет счастье

Даже без этого уже можно замутить очень мощную метасиситему

__>Мне вот непонятно теперь в чем преимущества Template Mixin если они легко эмулируются через Mixin Expression:

Мне кажется он просто вывел наружу механизм с помощью которого и были реализованны миксины.

__>

__>class A(T)
__>{
__> static const char[] v = "int a;";
__> mixin(v);
__>}
__>

__>Или так нельзя ?
__>Если нельзя то почему ?

Можно, плюс можно и рекурсивно создавать строку, что дает возможность генерировать к примеру структуры, хотя бы вот так:

template gen(L...)
{  
static if(L.length == 1)
    {
    const char[] gen = L[0].stringof ~ " x" ~ L.length.stringof ~ ";";
    }
else
    {
    const char[] gen = L[0].stringof ~ " x" ~ L.length.stringof ~ ";\n" ~ gen!(L[1 .. L.length]);    
    }    
}

struct S1
{
mixin(gen!(int, int, float));
}

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

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

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

Ну, что же. Поздравляю Ди. Это первый шаг к полноценным макросам.
Остается толоко добавить static while, static for, static... D

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

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

VD>Ну, что же. Поздравляю Ди. Это первый шаг к полноценным макросам.
VD>Остается толоко добавить static while, static for, static... D

Ты опоздал с поздравлениями: Compile-time interpretation
Пока в очень начальном состоянии, но события развиваются весьма быстро.

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

E>Ты опоздал с поздравлениями: Compile-time interpretation

Ссылка битая?

E>Пока в очень начальном состоянии, но события развиваются весьма быстро.

Это видно. Вообще люди явно занимаются фигней.
Им бы почитать про системы метапрограммирования в ФЯ. Глидишь дошли бы до правильных решений раньше.

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

Все конечно придумано до них, но боюсь они могут не понять идей так как сильно долеки от ФП (тут надежна на Александреску) или не принять этих по этой ричине

Автор: Lazy Cjow Rhrr
Дата: 12.02.07

.

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

E>>Ты опоздал с поздравлениями: Compile-time interpretation

VD>Ссылка битая?

Нет, рабочая.

E>>Пока в очень начальном состоянии, но события развиваются весьма быстро.

VD>Это видно. Вообще люди явно занимаются фигней.
VD>Им бы почитать про системы метапрограммирования в ФЯ. Глидишь дошли бы до правильных решений раньше.

VD>А то текстуальные конкатенации вместо квази-цитирования — это конечно лажа.
VD>Плюс им нужны средства декомпозиции и анализа кода, обеспечения гигиены (и ее управляемого нарушения) и т.п.

Я вот не понимаю, зачем изобретать новый Nemerle?
Или единственный правильный путь -- это тот, который в данный момент нравится лично тебе?

Брайт развивает D так, как ему нравится и прислушивается ко мнению авторитетных для него людей. Во многом результат этого развития мне нравится. В чем-то, в том числе и compile-time interpritation, нет. Тем не менее, язык получается весьма удобным и он не заставляет обязательно использовать все имеющиеся в нем возможности. Например, мне вообще compile-time вычисления и преобразования DSL в D код с их помощью не нужны, а вот текстовые mixin-ы и новый import -- как раз оказались весьма удобными.

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

E>Нет, рабочая.

В прошлый раз не открылась.
ОК. Что я могу сказать. Это лучше чем в С++ где для МП нужно применять совсем другой и ограниченный язык. Но это неверный путь. В идеале не должно быть разницы в метаязыке и обычном языке. Лисп и Немерле отлично показывают как все должно быть и даже дают пути решения. К тому же интерпретация — это похое решение для статически типизированного и быстрого компилятора.

E>Я вот не понимаю, зачем изобретать новый Nemerle?

Я тоже. Потому и не интересуюсь Ди. Ведь он явно или прийдет к Немерле или окажется хуже. (выоды сделаны на основании наблюдения за действями автора и комьюнити).
Но польза от второго Немерле есть. Ведь Ди изначально компилируемый в нэйтив-код язык. Это может оказаться многим полезно.

E>Или единственный правильный путь -- это тот, который в данный момент нравится лично тебе?

Путь то может и не единственный. И вариаций может быть много. Но направление известно. То что сейчас сделано в Ди — это ошибочный дизайн. Ошибок много. Но надежда есть, так как авторы видят неполноценность своих решений и ищут лучшие пути. Мне кажется основная проблема авторов Ди заключается в том, что они не анализировали опыт других метасистем. Они зациклились на создании лучшего С++.

E>Брайт развивает D так, как ему нравится и прислушивается ко мнению авторитетных для него людей.

Проблема в том, что похоже он Блаб-программист и не видет решений за пределами своего кругозора.

E> Во многом результат этого развития мне нравится.

Кое-что мне тоже. Но мета-система некудышная.

E> В чем-то, в том числе и compile-time interpritation, нет.

+1

E> Тем не менее, язык получается весьма удобным и он не заставляет обязательно использовать все имеющиеся в нем возможности.

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

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

Еще раз повторю, что это ошибки дизайна. Прошлый век. "Текстовые миксины" это недо квази-цитирование. То есть в нем еще не изобретен сплайсинг и гигиена. Боюсь, что автор языка просто пока не знаком с данными терминами. А import текстовых фвайлов вообще ошибка дизайна. Возврат к С. Остальс приделать дефайны к тексту и приплыли.

Могу подитожить свои мысли...

Итак на мой взгляд, в не зависимости от принятых решений, метасистема должа:
1. Позволять легкую копозицию кода.
2. Обеспечить контроль и отладку ошибок. Чем на более ранней стадии будет выявляться ошибка, тем лучше.
3. Использовать для создания метапрограмм тот же язык что и для обычных программ.
4. Обеспечить возожность анализа.
5. Обеспечить возожность модификации кода.
6. Обеспечить высокую производитльность метакода.
7. Разработать механизмы безсшовной интеграции мета-возможностей и основного языка. Это значит, что мета-реения должня быть естественными среди остального кода.
8. Обеспечить надежность метакода. Он не должен приводить к влетам компилятора. Ну, или свести такие возможности к минимуму.

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

Однако эти проблемы ничто по сравниню с проблемами Ди. Ведь в Ди проблемы идеологического плана. Плюс в Ди практически не паханное поле.

Очередные вести с полей

В digitalmars.D был задан вопрос о том, получилось ли у Александреску и Брайта придумать что-нибудь в области улучшения модели const-объектов в D. Александреску дал интересный ответ о том, что планируются следующие модификаторы:

a) final — a simple storage class controlling the immutability of the
bits allocated for the symbol per se;

b) const — type qualifier meaning an immutable view of an otherwise
modifiable data. const does not control the bits of the object, only the
storage addressed indirectly by it (transitively);

c) "superconst" — denoted as "const!" or "super const": type qualifier
meaning that the data is genuinely unmodifiable.

чуть более подробные объяснения, что же это значит, и примеры можно посмотреть здесь

Так же Александреску сказал, что планируется добавить в D возможность помечать методы классов как const и даже делать методы, которые являются, как он выразился, const-transporting методы. Т.е., чтобы не приходилось писать, как в C++:

class Container {
  Data get() {}
  const Data get() const {}
}

Так что остается ждать выхода сильно обновленного языка, D 2.0.

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

<skip>

Это вместо того чтобы сделать все константами по умолчанию, а для изменяемых объектов свои префиксы ?

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

__>Это вместо того чтобы сделать все константами по умолчанию, а для изменяемых объектов свои префиксы ?

Так ведь это же не функциональный язык, а улучшенный C++. И одна из задач разработчиков D -- сделать C++никам переход на D простым и комфортным. Пока у них получалось, но отсутствие внятной const-антности в языке до сих пор было одним из недостатков по сравнению с C++. Теперь этот недостаток планируют убрать. Может статься, что const-ы в D окажутся лучше const-в в C++, так же, как это произошло с шаблонами.

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

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

__>>Это вместо того чтобы сделать все константами по умолчанию, а для изменяемых объектов свои префиксы ?

E>Так ведь это же не функциональный язык, а улучшенный C++. И одна из задач разработчиков D -- сделать C++никам переход на D простым и комфортным. Пока у них получалось, но отсутствие внятной const-антности в языке до сих пор было одним из недостатков по сравнению с C++. Теперь этот недостаток планируют убрать. Может статься, что const-ы в D окажутся лучше const-в в C++, так же, как это произошло с шаблонами.

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

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

Это все игрушки. Лучше скажи что они там по поводу макросов думают?

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

VD>Лучше скажи что они там по поводу макросов думают?

Подробной информации я пока не видел. У меня вообще сложилось впечатление, что Брайт в каком-то узком круге сначала определяет дизайн новой фичи, потом ее делает, потом уже предъявляет общественности в готовом виде. А потом переделывает. Аналогично и с макросами -- может где-то что-то и проскакивало в списках рассылки, но мне не попадалось. Буквально сегодня Брайт сказал буквально следующее:

D will get macros — but they won't be text processing macros, they'll be abstract syntax tree (AST) processing macros.

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

E>Буквально сегодня Брайт сказал буквально следующее:
E>

E>D will get macros — but they won't be text processing macros, they'll be abstract syntax tree (AST) processing macros.

Ну, что же, направление мысли правуильное.

Тогда следующий вопрос (может задашь...).

Какие у него мысли по декомпозции кода? Без этого серьезная макросистема не мыслима.

В Немерле есть паттерн-матчиго, а АСТ организовано в виде алгеброических типов (идеальных для паттерн-матчинга). А как это будет выглядить в Ди?

Он вообще об этом думал?

Ну, и вытикающий отсюда вопрос. Не пора ли перепимать Ди на Ди? Глядишь тогда вопросы начнут рашаться побыстрее.

ЗЫ

И вот еще что. У Страуструпа в его "Дизайне и эволюции" сказана одна замечательная фраза. За точность не ручаюсь, но смысл примерно такой — "Людям не нужен лучший С++, им возможно нужен другой язык который предоставил бы значительно лучшие средства для решения те же проблем. С++ — этр не просто улученный С. С++ предоставляет программисту выбор новых парадигм.".

Понимает ли автор Ди, то что Ди это просто улучшеный С++? И не кажется ли ему, что Страуступ все же прав?

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

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

Объясни, пожалуйста, выделенное.

VD>ЗЫ

VD>И вот еще что. У Страуструпа в его "Дизайне и эволюции" сказана одна замечательная фраза. За точность не ручаюсь, но смысл примерно такой — "Людям не нужен лучший С++, им возможно нужен другой язык который предоставил бы значительно лучшие средства для решения те же проблем. С++ — этр не просто улученный С. С++ предоставляет программисту выбор новых парадигм.".

Имхо, D уже предоставляет значительно лучшие средства для решения тех же проблем.
Более того, глядя на свой C++ный код я понимаю, что на D он может быть портирован, а вот на другие языки (в первую очередь, Scala) -- только переписан.

PS. Что касается макросов, то сейчас Брайт начал приподнимать завесу над планирующейся макросистемой. Это будет что-то совершенно отличное от Nemerle-вого подхода. Но что именно я пока не понял.

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

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

E>Объясни, пожалуйста, выделенное.

Переписать Ди на нем самом же.

VD>>И вот еще что. У Страуструпа в его "Дизайне и эволюции" сказана одна замечательная фраза. За точность не ручаюсь, но смысл примерно такой — "Людям не нужен лучший С++, им возможно нужен другой язык который предоставил бы значительно лучшие средства для решения те же проблем. С++ — этр не просто улученный С. С++ предоставляет программисту выбор новых парадигм.".

E>Имхо, D уже предоставляет значительно лучшие средства для решения тех же проблем.

Дык ты видимо не понял то что имел в виду Страуструп. Просто лучше никому не надо. Нужны новые парадигмы. Нужно качественно лучше, а не количественно.

E>Более того, глядя на свой C++ный код я понимаю, что на D он может быть портирован, а вот на другие языки (в первую очередь, Scala) -- только переписан.

А смысл портировать код? Он приципиально не изменится. С точки зрения поддержки все останется так же. Убьешь кучу времени и все. О том и речь.

E>PS. Что касается макросов, то сейчас Брайт начал приподнимать завесу над планирующейся макросистемой. Это будет что-то совершенно отличное от Nemerle-вого подхода. Но что именно я пока не понял.

Интересно. Но боюсь, что он блаб в этой области. То есть он понимает, что что-то такое нужно, но вот как оно должно выглядеть он не знает. По крайней меере идей по декомпозиции я пока не вижу. А это будет решающим. Работать просто с АСТ практически невозоможно. Это черезвычайно сложно. Так что у него два варианта. Сделать макросы крайне ограниченными (например, только для генерации нового кода, но не для декомпозции), все же ввести в язык нечто более мощьное чем if/switch.