Здравствуйте, IT, Вы писали:
IT>Здравствуйте, c-smile, Вы писали:
CS>>Вопрос/опрос: Что бы вы добавили в язык D или его библиотеку?
IT>Макросы по типу Немерле. Слабо?
Игорь, а можешь в трех словах охарактеризовать что есть
макросы Нермерле?
Как я понимаю это фактически мета язык со своими правилами (очень непростыми)
ибо манипулирует он объектами AST. Правильно?
Здравствуйте, c-smile, Вы писали:
CS>Как я понимаю это фактически мета язык со своими правилами (очень непростыми) ибо манипулирует он объектами AST. Правильно?
Это всё тот же Немерле, на котором пишутся, скажем так для простоты, плагины к компилятору. Работа с AST сделана наиболее человеческим способом в терминах того же Немерле. Вот здесь куча примеров. То что заключено в <[ ... ]> это и есть работа с AST.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, c-smile, Вы писали:
CS>>Как я понимаю это фактически мета язык со своими правилами (очень непростыми) ибо манипулирует он объектами AST. Правильно?
IT>Это всё тот же Немерле, на котором пишутся, скажем так для простоты, плагины к компилятору. Работа с AST сделана наиболее человеческим способом в терминах того же Немерле. Вот здесь куча примеров. То что заключено в <[ ... ]> это и есть работа с AST.
Т.е. Немерле это фактически не язык а заготовка (Lego) для построения некоего проблемно ориентированного
языка или семейства языков.
Называть такую систему языком программирования я бы не решился ибо
видя штуки типа:
Я не ради очередного флейма, просто серьезно думаю, что лучше иметь язык со строгим синтаксисом и без большого количества подводных камней (как в D или Java по сравнению с C++) и расширять свой инструментарий за счет библиотек. В том числе и тех, которые кодогенерацию применяют.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, c-smile, Вы писали:
CS>Вопрос/опрос: Что бы вы добавили в язык D или его библиотеку?
На счет языка не знаю, за время моего последнего полного прочтения мануала (гда два назад) в D произошло много изменений. А вот чего не хватило для того, чтобы всерьез занятся изучением и применением D, так это отсутствие библиотеки, сравнимой с ACE. К самому языку и его стандартной библиотеке это не имеет непосредственного отношения. Но общее впечатление именно такое: вокруг D недостаточно еще продвинутых фреймворков/библиотек для того, чтобы браться за D в реальных проектах.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, c-smile, Вы писали:
CS>Т.е. Немерле это фактически не язык а заготовка (Lego) для построения некоего проблемно ориентированного CS>языка или семейства языков.
Нет. Nemerle это именно язык, причем общего назначения, а никакая не заготовка. И макросы наиболее хорошо подходят именно для надстройки над Nemerle, хотя проблемно-ориентированные языки на них тоже можно делать. Но будут они именно встраиваемыми, т.е. как расширение Nemerle, а не как что-то отдельное и независимое.
CS>Называть такую систему языком программирования я бы не решился ибо CS>видя штуки типа:
Nemerle — вполне полноценный язык программирования. По крайней мере такой же полноценный как C#.
А что касается этих "штук", то они играют весьма скромную и исключительно утилитарную роль в этой системе. И вообще это только для макро-атрибутов, которыми можно помечать различного рода объявления(типов, членов, параметров).
CS>сразу вспоминтается YACC. Может нужно просто сделать нормальный YACC CS>чтобы оделить мух от плевел так сказать... Или я не прав?
Yacc здесь совершенно ни при чем. Кроме того, что синтаксис псевдо-цитирования может отдаленно напоминать описание грамматик в Yacc и того, что встраиваемые генераторы синтаксических и лексических анализаторов это одна из наиболее подходящих задач для применения макросов Nemerle.
Здравствуйте, c-smile, Вы писали:
CS>Вопрос/опрос: Что бы вы добавили в язык D или его библиотеку?
Еще вот что подумалось. Лично мне было бы проще решиться на использование D, если бы развитие языка шло по другому сценарию. Я знаю про D уже несколько лет, а он все видоизменяется и видоизменяется. Новые версии компилятора содержат не только bug-fix-ы, но и изменения в языке.
Мне было бы выгоднее, если бы выпускалась фиксированная версия (например, 1.0.0). Далее развитие шло по двум ветвям. Ветвь 1.0.* -- содержит только bug-fix-ы и не изменяет сам язык. А изменения самого языка выполняются в версии 1.1.*, хоть до полной несовместимости с версией 1.0.0. Главно, будет понятно, что переход на новый релиз 1.0.* не будет требовать переписывать существующий код. А уже после того, как версия 1.1.* окончательно зафиксируется и будет выпущена как стабильная 1.2.0, тогда я уже сам буду решать, стоит ли на нее переходить, когда переходить, как этот переход делать и пр. Но в рамках ранее выпущенной 1.0.* для моего кода не будет неожиданных сюрпризов от изменений в языке.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, c-smile, Вы писали:
CS>Вопрос/опрос: Что бы вы добавили в язык D или его библиотеку?
Я бы в первую очередь выкинул бы back-end от Walter'а и окончательно заменил его на GCC. И выпустил бы windows-версию на основе Mingw. Затем бы переписал front-end на D и сделал его более самостоятельным/расширяемым(но это естественно может только WB).
Далее в порядке необходимости/значимости:
— утилиту для интероперабельности с C++ библиотеками(Walter Bright вполне мог бы сделать такую на базе его компилятора C++); типа SWIG, но более мощную/совместимую
— reflection/serialization
— возможность (полу)прозрачной интеграции библиотек на D с программами на C++
— переменное число параметров шаблонов(или встроенные списки типов)
— шаблонные операторы с неявной инстанциацией
— расширить библиотеку до уровня .NET BCL
c-smile wrote: > Вопрос/опрос: Что бы вы добавили в язык D или его библиотеку?
Более тщательно проработал бы взаимодействие с GC. Сейчас D может
работать только с консервным GC.
Ну и по мелочам: reflection, динамическую загрузку модулей.
IT wrote: > CS>Вопрос/опрос: Что бы вы добавили в язык D или его библиотеку? > Макросы по типу Немерле. Слабо?
В D есть static-код, работающий на этапе компиляции. В принципе, мне бы
его хватило для всех моих применений метапрограммирования.
Здравствуйте, c-smile, Вы писали:
CS>В качестве предисловия (нарисовалось вот чего-то): CS>
CS>Вопрос/опрос: Что бы вы добавили в язык D или его библиотеку?
Поздравляю вас товарщи с плавным перетеканием флуда про D в обсуждение:
И что характерно... Я ни слова не сказал.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Прекомпайл-тайм генерация имеет один идеологический изъян. Сгенерированные классы нельзя менять ручками, а часть класса/метода как дополнение к существующему классу/методу сгенерировать нельзя. Препроцессор в этом смысле значительно превлекательнее.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Прекомпайл-тайм генерация имеет один идеологический изъян. Сгенерированные классы нельзя менять ручками, а часть класса/метода как дополнение к существующему классу/методу сгенерировать нельзя. Препроцессор в этом смысле значительно превлекательнее.
Ну это уже сильно от кодогенератора зависит. Генерировать можно не весь класс, а только его часть (не для всех языков, однако такое прокатывает, тут препроцессор с поддержкой #include нужен). Можно в кодогенераторе предусматривать возможность вставки готовых фрагментов кода (например, как в yacc). Расширять сгенерированный класс можно за счет наследования (так в Qt сделано для наполнения функциональностей классов-диалогов, нарисованных в QtDesigner, из которых затем определения классов полностью генерируются). Возможностей не так уж мало.
Для меня наиболее предпочтительным является то, что на выходе есть готовый код в том же самом синтаксисе языка. Поэтому для разных IDE нет проблем для поддержки сгенерированных классов. С макропроцессорами и метапрограммированием ситуация для IDE гораздо сложнее.
ИМХО, однако.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, c-smile, Вы писали:
CS>>Вопрос/опрос: Что бы вы добавили в язык D или его библиотеку?
E>На счет языка не знаю, за время моего последнего полного прочтения мануала (гда два назад) в D произошло много изменений. А вот чего не хватило для того, чтобы всерьез занятся изучением и применением D, так это отсутствие библиотеки, сравнимой с ACE. К самому языку и его стандартной библиотеке это не имеет непосредственного отношения. Но общее впечатление именно такое: вокруг D недостаточно еще продвинутых фреймворков/библиотек для того, чтобы браться за D в реальных проектах.
Здравствуйте, eao197, Вы писали:
E>Мне было бы выгоднее, если бы выпускалась фиксированная версия (например, 1.0.0).
Согласен.
В принципе такой план у Вальтера есть.
Только чего-то это напоминает некий долгострой.
Слишком оно меделнно происходит. Версия 1.0 должна была
появится давно по идее. Года четыре это все длится
— в программерской жизни это очень долго.
Здравствуйте, Vermicious Knid, Вы писали:
VK>Я бы в первую очередь выкинул бы back-end от Walter'а и окончательно заменил его на GCC. И выпустил бы windows-версию на основе Mingw. Затем бы переписал front-end на D и сделал его более самостоятельным/расширяемым(но это естественно может только WB).
Да, но back-end от Walter'а генерирует хороший код. Лучше чем GCC.
VK>Далее в порядке необходимости/значимости: VK>- утилиту для интероперабельности с C++ библиотеками(Walter Bright вполне мог бы сделать такую на базе его компилятора C++); типа SWIG, но более мощную/совместимую
VK>- reflection/serialization
Да, но в natively compiled коде это сделать сложно да и не нужно в большинстве случаев.
VK>- возможность (полу)прозрачной интеграции библиотек на D с программами на C++ VK>- переменное число параметров шаблонов(или встроенные списки типов) VK>- шаблонные операторы с неявной инстанциацией VK>- расширить библиотеку до уровня .NET BCL
Здравствуйте, Cyberax, Вы писали:
C>c-smile wrote: >> Вопрос/опрос: Что бы вы добавили в язык D или его библиотеку? C>Более тщательно проработал бы взаимодействие с GC. Сейчас D может C>работать только с консервным GC.
C>Ну и по мелочам: reflection, динамическую загрузку модулей.
не-консервативный GC и reflection взаимосвязаны.
Я подозреваю что не-консервативный GC без какой никакой
reflection невозможен в принципе.
Если нам не помогут, то мы тоже никого не пощадим.
