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

M>Тут возникает небольшой ньюанс. Используя Common SQL мы так и не уходим от синтаксиса LIST, который, как мне кажется, уступает стандартному синтаксису SQL. Например, необходимость квотирования нужных фрагментов, запись арифметических выражений и т. д. Скажем последний select как для меня гораздо более вразумительнее выглядит в виде:

M>

select customer, item, quantity from header, detail where header_id = detail_id

Common Lisp имеет также макросы чтения, что в принципе позволяет записать запрос так:

(loop for (c i q) in #[SQL] select customer, item, quantity from header, detail where header_id = detail_id;
         do ...)

НО:
— синтаксис очень не похож на Лисповский, значит, будут проблемы с подсветкой, редактированием, сообщением об ошибках и т.д.;
— а также со вставкой Лисп-выражений в запрос (например, имени переменной name-id);
— видимый "исходный текст" радикально отличается от внутреннего представления, значит подняться еще на один мета-уровень будет сложно.

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

>> M>>Вот читаешь ветки: чего не хватает, чего не хватает... А почему
>> никто не спросит: что лишнего?
>> _W>RAII в С++ совершенно лишний. Потому что каждая компания пишет свой
>> Reflection и RAII.

Убейте меня! Я опечатался!
Вот что я хотел напечатать:
RTTIв С++ совершенно лишний. Потому что каждая компания пишет свой Reflection и RTTI под свои цели.

_Winnie wrote:
>
>>> M>>Вот читаешь ветки: чего не хватает, чего не хватает... А почему
>>> никто не спросит: что лишнего?
>>> _W>RAII в С++ совершенно лишний. Потому что каждая компания пишет свой
>>> Reflection и RAII.
>
> Убейте меня! Я опечатался!
> Вот что я хотел напечатать:
> *RTTI*в С++ совершенно лишний. Потому что каждая компания пишет свой
> Reflection и *RTTI* под свои цели.

Он там не то, чтобы лишний. Он там совершенно unusable. Причем настолько
unusable, что самодельный reflection/RTTI даже не может опираться на
родной как на основу, и существует совершенно независимо от него...

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

M>У меня тяга не совсем к к метапрограммированию. У меня тяга к созданию компиляторов. Более радикальный подход. Скажем так, чтобы новые возможности в язык можно было вносить не средствами самого языка, а прямой правкой исходников транслятора. Ну и чтобы обеспечить наиболее удобные механизмы как для этого...

править сам компилятор слишком трудно, да и опасно
по хорошему, компилятор должен обеспечивать только каркас, а описание собственно языков — с помощью специально под это заточенного DSL