CL быстрее прочих :)

>В стандарте С++ 97-го года была предусмотрена раздельная компиляция шаблонов, почему никто не использовал их?

Наверное, потому что ее никто не реализовал.

Я хочу сказать то, что сказал: ни Грэхэм, ни Норвинг, не использовали CLOS.

Разве это потому что в их время его не было? Может ты хочешь сказать, что за 14 лет изменился подход, но не язык?

> Нет, только те, где определяется синтаксис,

специфичный для решения какого-то класса проблем.

Что такое синтаксис в твоём понимании? В CL же по сути его нет? А как насчёт стадии трансформации?

> Разве это потому что в их время его не было? Может ты хочешь сказать, что за 14 лет изменился подход, но не язык?

А тред почитать слабо?

> Разве это потому что в их время его не было?

А какие из доступных реализаций его поддерживали? И насколько была высока степень совместимости между реализациями? Я полагаю, что в первую очередь да. CLOS настолько хорошо, что не пользоваться им (там где он походим) можно только если его нет.

Может ты хочешь сказать, что за 14 лет изменился подход, но не язык?

И об этом я тоже здесь говорил.

Что такое синтаксис в твоём понимании? В CL же по сути его нет?

Ну да. То, что CL поощряет по каждому чиху писать edsl (который от api отделить сложно, ибо жёстких критериев нет) - это не значит, что базового синтаксиса нет.

А как насчёт стадии трансформации?

Разверни мысль.

> который от api отделить сложно, ибо жёстких критериев нет

Угу, в чём тогда смысл говорить об этом? Однако, критерии есть, ибо Domain Specific Language это на API, которое, по сути, всегда domain specific.

Разверни мысль.

Традиционно DSL предусматривает трансформацию кода (записанного в синтаксисе DSL), в нечто другое, что потом можно исполнять (либо какая-то внутренняя структура, либо код на целевом языке). Очень многие макросы в CL используют параметр &body, в котором типично передаётся код, но он практически никогда специальным образом не обрабатывается, а вставляется как есть, его окружают плюшками разными, но никакой стадии трансформации нет. Иногда бывает более сложное использование, когда действительно имеет место стадия трансформации и когда можно говорить о eDSL, например s-sql, iterate или даже cl-who. Но такая техника на практике используется редко. Иначе ведь можно заявить, что макросы в C тоже определяют DSL (хоть и не так удобно).

>А тред почитать слабо?

Он не настолько интересен.

Очень многие макросы в CL используют параметр &body, в котором типично передаётся код, но он практически никогда специальным образом не обрабатывается, а вставляется как есть, его окружают плюшками разными, но никакой стадии трансформации нет.

&body - это, своего рода, аналог &rest. Т.е. та часть DSL-выражения, содержимое которой по отдельности не интересует. Макрос же DSL-терм может трансформировать по самое не хочу.

Иначе ведь можно заявить, что макросы в C тоже определяют DSL (хоть и не так удобно).

Несомненно. На макросах сишного препроцессора можно свободно написать программу, которая по своему внешнему виду на Си будет не похожа.

>А какие из доступных реализаций его поддерживали?

Даже и не слышал о лиспе в 1994. Инфа о неподдерживаемости CLOS в те темные времена достоверна? Просто в вики есть ссылка на такую книжку: http://en.wikipedia.org/wiki/Object-Oriented_Programming_in_Common_Lisp:_A_Pr...

1988 год неиллюзорно намекает, что в 1994 CLOS уже существовал.

Посмотри исходный код cl-who. Это отвратительная по своим техническим характеристикам библиотека (ибо реализует дурную идею). Но очень показательный и лёгкий для понимания пример построения eDSL на Common Lisp. Там как раз в макросе with-html-output передаётся параметр &body, но содержимое этой части, вопреки твоим словам, очень даже интересно. Для его трансформации вызывается функция с говорящим именем tree-to-commands, которая сложным образом обрабатывает передаваемое s-выражением и генерирует на его основе код на CL, который и подставляется в макрос with-html-ouput. Таким образом, в данном случае макрос with-html-output нужен только для синтаксичего сахара, что бы можно было удобно использовать функцию tree-to-command, которая обеспечивает реализацию eDSL. Здесь хорошо видно, что основой создания eDSL в Common Lisp являются вовсе не макросы, а символьное представление кода, пресловутое единство кода и данных. Проблема лишь в том, что эта техника достаточно сложна, ибо язык не предоставляет особой инструментальной поддержки (ну кроме возможностей по манипулированию символьными выражениями), которая сейчас однако уже есть в некоторых других языках.

>Иногда бывает более сложное использование, когда действительно имеет место стадия трансформации и когда можно говорить о eDSL, например s-sql, iterate или даже cl-who. Но такая техника на практике используется редко.

Традиционно DSL предусматривает трансформацию кода (записанного в синтаксисе DSL), в нечто другое

Два непротиворечивых утверждения, из которых следует, что написание eDSL в clisp возможно. Да, трансформация полностью ручная, от чего кажется громоздкой. Благодаря этому же качеству трансформация достаточно проста для понимания.

> Инфа о неподдерживаемости CLOS в те темные времена достоверна?

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

Блин, ведь есть же реализация C++ c поддержкой раздельной компиляции шаблонов, но книг, её использующих нет. А в какому году появились книги, где начали использовать частичную специализацию шаблонов? Аналогия, надеюсь, понятна.

Там как раз в макросе with-html-output передаётся параметр &body, но содержимое этой части, вопреки твоим словам, очень даже интересно. Для его трансформации вызывается функция

То есть это обработка данных в рантайме? Так же, как в, например, format. А макрос with-html-output - это типа удобной обёртки над выводом, и он к функции обработки данных особого отношения не имеет.

>Блин, ведь есть же реализация C++ c поддержкой раздельной компиляции шаблонов, но книг, её использующих нет.

Нету таких реализаций. Просто потому что их нельзя раздельно компилировать. То, что в comeau (вроде) поддерживается слово «export», не означает, что от его применения есть профит.

> То, что в comeau (вроде) поддерживается слово «export»,

не означает, что от его применения есть профит.

Не, ну есть профит или нет, это совсем другая история, гы )) Есть ключевое слово export, есть его реализация, стандарт удовлетворён.

> То есть это обработка данных в рантайме?

Почему? Генерация происходит на этапе компиляции, естественно.

(defmacro with-html-output ((var &optional stream
                                 &key prologue
                                      ((:indent *indent*) *indent*))
                            &body body)
  "Transform the enclosed BODY consisting of HTML as s-expressions
into Lisp code to write the corresponding HTML as strings to VAR -
which should either hold a stream or which'll be bound to STREAM if
supplied."
  (when (and *indent*
             (not (integerp *indent*)))
    (setq *indent* 0))
  (when (eq prologue t)
    (setq prologue *prologue*))
  `(let ((,var ,(or stream var)))
    ,(tree-to-commands body var prologue)))

Обрати внимание на вызов функции tree-to-commands и использование результата вызова на этапе компиляци.

> Потому что он не просто уплотнил массив локов, но и перетасовал его.

1. Хорошо, пусть он уплотнил и не перетасовал. Но имеется еще программист Д, который сравнивал локи не по оффсету в массиве (или разности указателей), а по физическому адресу, скастованному к ЗНАКОВОМУ 32-разрядному целому. И у программиста Д все прекрасно работало, даже если массив начинался по адресу 0х7FFFFF00. Но вот подключение *нетасующего* уплотнителя С приводило к очень редким глюкам...

2. Откуда С должен был знать, что перетасовывать нельзя? Ведь в коде класса Lock *ничего* об этом не говорит. И на самом деле перетасовывать было можно. Кстати, вполне возможно программист С написал Уплотнитель Памяти Общего Назначения, Статически Анализирующий Код Классов, а не явно направленную диверсию против Lock.

З.Ы. если речь идет *вообще* о сборке мусора в с/с++, то какие-то классы надо запретить двигать; вроде как вовсе не всегда эффективно не тасовать объекты, или опять применить двойной указатель... но общий пойнт в том, что может найтись вот такое неожиданное использование указателя; хотя вариант монотонного изменения адресов объектов тоже стоит обдумать

Это как-то говорит о том, что макросы, не лезущие в body, DSL'ем являться не могут?

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

Например? Мне очень интересно узнать, где по-твоему поддержка метапрограммирования лучше, чем в CL(особенно интересно, если примеры не будут лисповые). Не троллинга ради, а интереса для.

> Это как-то говорит о том, что макросы, не лезущие в body,

DSL'ем являться не могут?

Обычно нет, ибо нет трансформации. Макросы это просто способ выполнить произвольный код на этапе компиляции, плюс несколько плюшек.

> Мне очень интересно узнать, где по-твоему поддержка

метапрограммирования лучше, чем в CL(особенно интересно,

если примеры не будут лисповые).

Haskell же!

>Блин, ведь есть же реализация C++ c поддержкой раздельной компиляции шаблонов

Comeau? Он не сильно распространен, так что можно сказать, что компиляторов с поддержкой этой фичи просто нет.

А в какому году появились книги, где начали использовать частичную специализацию шаблонов?

Емнип использовать продвинутые техники стали после отмирания VC 6.0 (забавно, кстати, что IE 6.0 и VC 6.0 были широко распространенным полным говном, тормозящим технический прогресс), который все эти техники не поддерживал.

Обычно нет, ибо нет трансформации.

Ну здрасьте! В редакторе (foobar bla-bla), а после макроэкспанда - развесистая лаша, зависящая от bla-bla.

Макросы это просто способ выполнить произвольный код на этапе компиляции, плюс несколько плюшек.

И разве это не является частью механизма реализации DSL (т.к. говорим о лиспе, подразумевается eDSL)? Причём, существенной такой?

> Емнип использовать продвинутые техники стали после отмирания VC 6.0

Не надо мне это рассказывать, я всё прекрасно знаю (ибо написал на C++ гораздо больше кода, чем на CL), я просто пытался провести понятную аналогию ;)

> Ну здрасьте! В редакторе (foobar bla-bla), а после макроэкспанда -

развесистая лаша, зависящая от bla-bla.

Ну и что? В С++ мы тоже пишем невинное std::vector<std::string>, а компилятор столько лапши подставляет, но от этого std::vector не становится DSL.

И разве это не является частью механизма реализации DSL

Понятие DSL абсолютно ортогонально понятию времени исполнения. Макросы же напротив, тесно с этим понятием связаны и появились потому, что часто полезно выполнять код на этапе компиляции. Если обработку DSL удобней проводить на этапе компиляции, то проще всего запихнуть это в макрос (можно с eval-when шаманить, но будет менее удобно). Однако, того же итогового эффекта можно было бы добиться и с помощью функций + eval-when, просто было бы менее удобно.

в восьмидесятых была точно книжка по CLOS или его предшественнику... сам в руках держал... мировское что то скорее всего

> Обычно нет, ибо нет трансформации

Однако, штангисты создают DSL без какой-либо трансформации кода.

> кстати, что IE 6.0 и VC 6.0 были широко распространенным полным говном

Ложь и провокация. Для своего времени VC 6.0 был очень хорошим компилятором. На уровне Watcom.

в восьмидесятых была точно книжка по CLOS или его предшественнику...
сам в руках держал... мировское что то скорее всего

Угу, только CL ещё не было ;) Точнее, даже был, наряду с кучей других диалектов. И с объектными системами многие реализации экспериментировании, много их разных было. А об ООП при этом знали единицы. Признание важности и роли ООП произошло намного позже, тем более, в такой ортодоксальной среде, как лисперы, которые всегда считали себя самыми умными: типично в молодости они видели Алгол и ещё что-нибудь такое, а потом познакомившись с лисп признали его верхом совершенства и больше ни с чем не хотели иметь дело. А время шло. В начала 2000-ых (кажется в 2002) на comp.lang.lisp был эпический срач «Как я потерял веру», который инициировал человек всю жизнь работавший с лисп, но придя на работу в Google обнаружил, что многие с Python оказываются более производительными чем он. Я тогда про CL ничего не знал, но позже просматривал архивы.

Перелом в повсеместном использовании CLOS, да и вообще в технике использования CL, случился только после того, как в CL пришли новые люди, у которых был опыт работы с другими современными языками. Они увидели что язык хорош (ибо это объективно так) и начали использовать, использовать не только традиционные для лисп технии, но и те, что используют в других языках.

Вообще, всё это мой глубокое ИМХО, ибо я тогда вообще ничего про это знал, но такой мне видится ситуация сегодня на основе того, что я знаю.

> Однако, штангисты создают DSL без какой-либо трансформации кода.

Хм, и как же они их создают? Примеры DSL на Haskell, которые я видел, произвели на меня достаточно сильное впечатление. И там точно была трансформации. Может у нас опять путаница в терминологии?

> Ложь и провокация. Для своего времени VC 6.0 был очень

хорошим компилятором.

Для какого? Стандарт приняли в 97 года, 6.0 вышла в 98-ом. Если оценивать его не на основе других реализаций, а на основе поддержки стандарта, то это было полное УГ.

> Может у нас опять путаница в терминологии?

Она у нас происходит на ЛОРе с завидной регулярностью, причем главный зачинщик терминологических споров очень хорошо известен в узких кругах.

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

> Она у нас происходит на ЛОРе с завидной регулярностью, причем

главный зачинщик терминологических споров очень хорошо известен

в узких кругах.

Слушай, откуда вообще такая манера всегда говорить полунамёками, никогда при этом не проясняя чётко свою позицию? Фобия?

Хорошо, вот цитата из одного документа:

In practical, Template Haskell allows the programming to alter the semantics of a program by transforming it into a diferent program before it reaches the compiler.

Нагло врут?

Все гораздо проще. Я так компенсирую недостаток чувства юмора.

> Все гораздо проще. Я так компенсирую недостаток чувства юмора.

Однако со стороны больше похоже на избыток чувства страха.

И причем здесь Template Haskell? Посмотри на парсер-комбинаторы. Там свой DSL. И такие парсер-комбинаторы есть для F# и Scala, где нет и намека на трансформацию кода (хотя вру, в F# код может трансформироваться, но через вычислительные выражения, а в Scala трансформируются выражения reset для продолжений). Просто понятие DSL настолько широкое, что я даже не знаю, что нельзя им назвать. Как-то заглянул на википедию, а там столько много-букав, что не стал читать :)

В общем, грань между DSL и API весьма условная. И чем более высокоуровневый язык, тем она условнее. Просто становимся ближе к предметной области.

В начала 2000-ых (кажется в 2002) на comp.lang.lisp был эпический срач «Как я потерял веру», который инициировал человек всю жизнь работавший с лисп, но придя на работу в Google обнаружил, что многие с Python оказываются более производительными чем он.

Я тебе открою секрет, что каким бы ты крутым себя не считал, но придя в компанию уровня Гугля, ты обнаружишь, что там валом людей и умнее, и производительнее тебя ;)

Личный опыт.

Однако со стороны больше похоже на избыток чувства страха.

Фигасе, предъявы.

> Просто понятие DSL настолько широкое, что я даже не знаю,

что нельзя им назвать.

Столь широкие понятия, которыми можно назвать всё что угодно, не имеют какого-либо смысла, по крайней мере, при обсуждении технических вопросов, их и не используют. И понятие DSL, в том виде как оно используется в технической литературе, таковым не является. Поэтому, пожалуйста, не надо ссылаться на википедию, сошлись лучше на известного автора, специалиста по DSL.

И да, у тебя явные проблемы с терминологией.

> Я тебе открою секрет

Хм, зачем ты мне его будешь открывать? Лучше бы открыл его тому бедняге, ну да поздно уже. Факт в том, что данная дискуссия в своё время вызывало большой резонанс (такой, что я несколько лет спустя не раз натыкался на её упоминания) и кажется отражает общую проблему.

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

Ну да! Вместо «двигатель» нужно обязательно говорить «рядный трёхцилиндровый дизельный двигатель внутреннего сгорания объёмом 1422 кубических сантиметров, 474.1 на цилиндр, цилиндр 79.5 x 95.5 мм, с турбонагнетателем и прямым впрыском, степенью компрессии 18.0:1», чтобы не дай бохх не ввести никого в заблуждение относительно предмета дискуссии?

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

Одинаковые социально-психологические драмы случаются в каждом поколении людишек, к технологии они отношения мало имеют. И пока эта драма не моя личная, мне на неё накласть с большой колокольни :)

> Вместо «двигатель» нужно обязательно говорить

Зависит от предмета обсуждения, очевидно. Используемая терминология должна обеспечивать целостность и логическую законченность приводимых утверждений и аргументов.

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

Да не хочу я с тобой спорить! Успокойся. Но если будет желание и время, открой книгу Programming in Scala. Там выражение domain specific language используется очень часто.

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

Как переводится DSL ты знаешь. Если мне нужно, например, при описании foreign-структуры в cffi вызывать какое-то своё действие, я создаю макрос, реализовывая тем самым метаязык над языком описания структур в cffi. Про трансформацию речи не идёт.

> реализовывая тем самым метаязык над языком описания структур в cffi

Опять метаязык, который язык для описания языка. И как прикажешь это понимать? cffi:defcstruct вызывается для описания какого языка? Кажется только для описания структуры данных, которая никак не язык.

Ладно. В cffi:defcstruct передаются просто пары - «имя поля»/«тип поля», тупо список пар. Извини, называться языком (тем более метаязыком) это никак не может. При этом, этот функционал можно было бы спокойно оформить и в виде функции. Основная причина почему этот макрос в том, что обычно данные вычисления надо проводить именно на этапе компиляции.

>Для своего времени VC 6.0 был очень хорошим компилятором

Только «свое время» как-то неоправданно затянулось. К примеру, начиная с некоторого времени, g++ уделывал шестерку в плане поддержки нетривиального кода. И то, как охотно перепрыгнули на следующую версию компилятора, однозначно намекает, что старая никому особо не нравилась.

язык это тогда: 1) ты ввел операторы 2) их можно комбинировать и в идеале 3) комбинацию операторов можно подставить вместо любого из операторов

Под это определение cffi:defcstruct, очевидно, не подходит.