Здравствуйте, eao197, Вы писали:
E>Внешний DSL и pre-compile-time генерация кода. Чтобы можно было получить результат этой генерации в виде чистого C++ кода.
Ну, и в чем тут логика? Не лучше ли получить интегрированное решение в котором можно было как отлаживать генерируемый код, так и производить отладку на более высоком урочне — уровне этого самого ДСЛ-я?
E> Чтобы затем отладчиком по нему пройтись можно было.
Дык, и так можно сделать, так чтобы по генерируемому коду можно было отладчиком ходить.
А вот у внешних ДСЛ-ей крайне ограничены области применения, так как они не могут взаимодействовать с основным языком, да и других проблем хватает.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, jazzer, Вы писали:
J>Не надо никому из пишущих на С++. Ты, очевидно, к ним не относишься.
Дык их все меньше и меньше. Сейчас С++ еще живет по инерции. Но пройдет время и она пойдет на спад. Тогда на нем будут только фанатики работать и те кому плевать на все кроме производительности.
J>Если это будет соответствующим образом гранулироваться — я только за. И, опять же, совсем не 2 режима (все или ничего), а отдельное управление каждой "опасной" фичей.
Скажем так. Должен быть безопасный скоп, а уж отключать безопастность можно и гранулярно.
Вот только у С++-ных комитетчиков мозг сварился много лет назад. Они даже не будут думать подоным образом (к сожалению). Они тупо свалят все в кучу и в 0х будут только расширения которые просто добъют язык увеличением сложности.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Вот сильно сомневаюсь, что такие вещи, как константность, замыкания, lazy-аргументы, scope-классы и scope.exit, design by contract могли бы уехать в стандартную библиотеку.
Так в немерле половина того что ты перечислил туда и уехала.
Причем изначально это делали посторонние люди.
E>Ну или метапрограммирование на шаблонах, которое использует побочный эффект.
Это делается исключительно из-за того что нет нормальных макросов.
E>И, в моем понимании, нормальный язык и должен так развиваться. Все нововедения только через основную команду разработчиков.
Основная команда разработчиков не резиновая.
E>Так вот мне и кажется, что если разработчик не смог придумать такие высокоуровневые классы и методы, которые бы позволили лаконично решить задачу, то где гарантия, что он сможет сделать это с помощью языка?
В техже компиляторах есть куча кода которая генерится по шаблонам.
Никаким ООП это не объехать.
J>>Ты за деревьями теряешь лес. Все навороты и фичи языков нужны исключительно для того, чтобы сделать прикладной код проще, понятнее и безопаснее, не более того, а не для того, чтобы написать "MegaMacroBoost, в деталях реализации которого вообще мало кто сможет разобраться".
E>Иногда для получения нужных характеристик прикладного кода нужно понимать, как устроены и работают задействованные библиотеки. Если понять это сложно, то и на качестве прикладного код это отразиться обязательно.
Не вижу связи.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>А вот у внешних ДСЛ-ей крайне ограничены области применения, так как они не могут взаимодействовать с основным языком, да и других проблем хватает.
Тоже самое можно сказать и про встроенные DSL-и.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Так вот когда мы говорим о встраивании DSL-ей внутрь языка, то хотелось бы, чтобы любой инструмент, который расчитан на этот язык, мог правильно и осмысленно понимать наши DSL-и. И если DSL представляет средства для работы с регулярными выражениями, то хотя бы подсвечивать эти выражения соответствующим образом.
+100
E>А ты можешь сравнить легкость и скорость разработки парсеров, например, при помощи Coco/R, ANTLR или Ragel и Boost.Spirit? Ведь дело в том, что они уже давно далеко ушли вперед по сравнению с lex/yacc. И вызов методов/сохранение результатов там так же делается тривиально.
Boost.Spirit не самый плохой генератор парсеров. Его проблемы в основном заключается в том, что оне не предоставляет полноценной диагностики ошибок в грамматике. Но это из-за того, что он реализован средствами шаблонного метапрограммирвоания, которое, как ты наверно знаешь, не является штатным средством языка, а потому сопряжено с кучей ограничений и проблем. То же решение на Немерле было бы вполне конкурентноспособным с АНТЛР-ом и даже было бы более удобным, так как мы получили бы более тесную интеграцию с языком на котором производится семантический анализ (надеюсь ты знашь, что генераторы парсеров его не автоматизирвют?).
E>Я больше чем уверен, что разобраться в коде, сгенерированном Ragel или ANTLR вообще удасться, т.к. там используются специальные алгоритмы для генерации оптимального кода для парсинга конкретной граматики. Т.е. генерируется специфический конечный автомат. Посмотри, например, на стартовой страничке Ragel-я пример того, что он строит.
АНТЛР генерирует рекурсивный парсер с откатами на исключениях.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Тоже самое можно сказать и про встроенные DSL-и.
Нет. Все что умеют внешние ДСЛ-и делается встроенными. По сути встроенный ДСЛ всгда можно осформить как отдельную сущьность.
Как пример можно взять те же генераторы парсеров. Их можно делать как встроенным ДСЛ-ем, так и внешним. Тот же Спирит пример построителя парсера реализованного в виде встроенного ДСЛ-я, а АНТЛР — внешнего.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
E>>Тоже самое можно сказать и про встроенные DSL-и.
VD>Нет. Все что умеют внешние ДСЛ-и делается встроенными. По сути встроенный ДСЛ всгда можно осформить как отдельную сущьность.
Уметь-то они могут многое, только что-то может быть нафиг не нужно.
Например, зачем иметь DTD в виде встроенного DSL?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Уметь-то они могут многое, только что-то может быть нафиг не нужно. E>Например, зачем иметь DTD в виде встроенного DSL?
Не нужно, так не нужно. А вот когда нужно будет, то хотелось бы иметь средства (прямые, ане как метапрограммирование на шаблонах) для реализации задуманного.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Тут не понял. Язык -- это набор неких концепций, неких кирпичиков. Чем логичнее и целостнее этот набор, тем лучше. На основе этих кирпичиков нужно создавать прикладные решения. А если язык предлагает достраивать сам себя, то вот это мне и не нравится. Язык должны достраивать разработчики языка, а не пользователи.
Здравствуйте, deniok, Вы писали:
D>Здравствуйте, Стэн, Вы писали:
D>C--?
Да, спасибо, мне уже подкидывали эту ссылку... Я посмотрел, но вот что я не особо понимаю. Если писать некий код руками, то в качестве высокоуровневого ассемблера (как С) его не очень удобно использовать?! И ли лучше?
А вот если у меня есть какой-то высокоуровневый язык, заточенный под мои задачи, то я могу написать свой компилятор, а могу транслировать свой код в код C--, а потом его откомпилировать. Это его основная задача?
Здравствуйте, Стэн, Вы писали:
С>Здравствуйте, deniok, Вы писали:
D>>Здравствуйте, Стэн, Вы писали:
D>>C--? С>Да, спасибо, мне уже подкидывали эту ссылку... Я посмотрел, но вот что я не особо понимаю. Если писать некий код руками, то в качестве высокоуровневого ассемблера (как С) его не очень удобно использовать?! И ли лучше?
Здесь вопрос — какой код писать руками? Если реализовывать низкоуровневые вещи, то, вроде, поудобнее (как я понял он больше гарантий дает чем C по поводу стековых фреймов, допускает jump, разные calling conversion, и т.п.). То есть свой GC реализовать легче, ну и свои механизмы exception handling, concurrency, profiling и debugging тоже, говорят, поудобнее делать. Но я сам только проглядывал статьи, не более.
С>А вот если у меня есть какой-то высокоуровневый язык, заточенный под мои задачи, то я могу написать свой компилятор, а могу транслировать свой код в код C--, а потом его откомпилировать. Это его основная задача?
Здравствуйте, eao197, Вы писали:
E>Я больше чем уверен, что разобраться в коде, сгенерированном Ragel или ANTLR вообще удасться, т.к. там используются специальные алгоритмы для генерации оптимального кода для парсинга конкретной граматики. Т.е. генерируется специфический конечный автомат.
antlr для паресера никаких автоматов не генерит, там банальный рекурсивный спуск. Ну разобраться в этом коде просто.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>antlr для паресера никаких автоматов не генерит, там банальный рекурсивный спуск. Ну разобраться в этом коде просто.
Потому и просто. Правда вроде как 3.0 хотели на автомат перевести. Вот там будет задница.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Я бы тупо ввел два режима. VD>2. Режим 0х в котором многое запрещено и не допустимо, но зато обеспечивается полноценный контроль. Первое что я бы запретил — это препроцессор. Второе — использование указателей. Третье — программироание шаблонов без концептов.
С такими ограничениями этот второй режим тогда нафиг никому не нужен. Это уже не C++.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, EvilChild, Вы писали:
VD>>Вот только в тех же плюсах есть сильно недотипизированные куски кода вроде шаблонов (до реального применения во многих местах вообще мало что сказать можно).
EC>Concepts эту задачу решают. Некий аналог классов типов Хаскеля.
К сожалению в плюсах шаблоны изначально криво встроенны , и Concepts эти слабая попытка лечения. А вылечить концептальные проблемы скорее всего не получится.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, EvilChild, Вы писали:
VD>>>Вот только в тех же плюсах есть сильно недотипизированные куски кода вроде шаблонов (до реального применения во многих местах вообще мало что сказать можно).
EC>>Concepts эту задачу решают. Некий аналог классов типов Хаскеля.
M>К сожалению в плюсах шаблоны изначально криво встроенны , и Concepts эти слабая попытка лечения. А вылечить концептальные проблемы скорее всего не получится.
шаблоны придуманы Страуструпом для простых вещей типа vector<>
int f(char);
void f(...);
int g=sizeof(f(g));
Противоестественные конструкции появились поздже, а шаблоны какими были изначально, такими и остались. Комитет заместо добавления чегото нужного занимался документированием багофичей. И такими вещами никому не нужными как std::mask_array
Здравствуйте, CreatorCray, Вы писали:
VD>>Я бы тупо ввел два режима. VD>>2. Режим 0х в котором многое запрещено и не допустимо, но зато обеспечивается полноценный контроль. Первое что я бы запретил — это препроцессор. Второе — использование указателей. Третье — программироание шаблонов без концептов. CC>С такими ограничениями этот второй режим тогда нафиг никому не нужен. Это уже не C++.
Это зависит от равития личности. Если она ничего кроме С++ в своей жизни не видела, то несомненно — да.
Хорошие же С++-программисты и в данный момент используют ограниченный сабсет С++ прибегая к его опасным частям только по необходимости. Проблем у такого подхода две 1) контроль возлагается на человека и стало быть надежность программ гарантировать нельзя, 2) языковые средства подобного сабсета сильно ограничены.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, minorlogic, Вы писали:
EC>>Concepts эту задачу решают. Некий аналог классов типов Хаскеля.
M>К сожалению в плюсах шаблоны изначально криво встроенны , и Concepts эти слабая попытка лечения. А вылечить концептальные проблемы скорее всего не получится.
Здравствуйте, EvilChild, Вы писали:
M>>К сожалению в плюсах шаблоны изначально криво встроенны , и Concepts эти слабая попытка лечения. А вылечить концептальные проблемы скорее всего не получится.
EC>А что с шаблонами не так?
То что используемый контракт налагаемый на шаблонный класс нигде явно не выражен.
