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

>archimag говорит, что есть макросы которые ожидают чего-то, а есть те что ничего не ожидают а просто вклеивают свои body и подставляют прочее.

между этими условными двумя типами макросов нет чёткой грани. А уж строить на этом систему определения eDSL-ей...

> Но это остаётся вашим ИМХО - не более.

Акроним «ИМХО» используется для утверждений, которые не имеют чёткого логического обоснования, либо когда автор не может его привести в силу объективных причин, например, когда не всё известно о обсуждаемом вопросе и приходиться полагаться на экспертную оценку. Таким образом, его нельзя использовать для характеристики цепочки логических рассуждений, ибо законы логики не связаны с личностью автора рассуждений. С логикой можно либо согласится, либо опровергнуть (например, указать что она основывается на ложных представлениях ). Т.е. никаких «имхо» здесь не может быть в принципе.

Но не суть. Основная проблема в том, что понятие DSL является широко известным и разрекламированным (как мощный инструмент решения различных проблем) людьми, которые не имеют никакого особого отношения к лисп (взять, например, того же Фаулера). Некоторые лисперы пытаются «примазаться» к популярности DSL и обосновать превосходство CL тем, что он якобы очень хорошо подходит для создания DSL. Но при этом, они отказываются как либо чётко определить, что же такое этот Domain Specific Language и используют его для описания всего подряд, тем самым искажая и обесценивая понятие DSL.

Вот как раз такая риторика, основанная на искажениях и льстивых обещаниях, как раз и называется ДЕМАГОГИЕЙ.

> Разработчиков хаскеллевых компиляторов вообще нужно в угол поставить, что они до сих пор не всех подряд в клочья рвут.

John Harrop любит поговорить на эту тему. Утверждает, что хаскель не дружит с кешем процессора (из-за ленивости, санков), а без этого не видать космической скорости.

John Harrop любит поговорить на эту тему. Утверждает, что хаскель не дружит с кешем процессора (из-за ленивости, санков), а без этого не видать космической скорости.

Т.е. если писать строго энергичный код, то хаскелль на паровозе вперёд вырвется?

Так и запишем: «Мартин Одерский занимается демагогией» :)

> Т.е. если писать строго энергичный код, то хаскелль на паровозе вперёд вырвется?

А как ты его там напишешь? Если серьезно, то фиг знает, каким был бы энергичный хаскель с его пуризмом.

Энергичный — имеется в виду «не ленивый».

> > Хаскельные компиляторы развиваются не только в сторону увеличения производительности. В отличии от того, что застряло в старом стандарте.

Я говорю о конпеляторе, а не о стандарте.

Я тоже.

Чуешь разницу?

Да, а ты? :)

> Т.е. если писать строго энергичный код, то хаскелль на паровозе вперёд вырвется?

Не вырвется. Но, кто его знает, может придумают какую плюшку для ghc в этом плане.

Хаскельные компиляторы развиваются не только в сторону увеличения производительности. В отличии от того, что застряло в старом стандарте.

Я говорю о конпеляторе, а не о стандарте.

Я тоже.

Ну и что ты тогда хотел той своей фразой сказать?

Знаю. «Энергичный хаскель» значит воображаемый.

>> почти любой макрос вводит «свои семантические правила».

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

что далеко ходить — возьми анафорический if. И деление на аргумент, если он не 0 в этот if. «Семантическое расширение, или правило» — это принцип «вычисляется тот аргумент then/else, который определяется условием в if». Если бы «семантического правила» не было бы, то вычислялось бы деление на 0 в любом случае, и ловили бы ошибку (хотя в половине случаев это вычисление не нужно).

Аналогично с любым макросом — использование `(.. ,foo) или `(... foo)

Эти «семантические правила» задаются:
1. необходимостью вычисления конкретных аргументов макроса
2. логикой такого вычисления

Ровно то, что сказал, сказать и хотел. Еще раз: гхц ориентирован не только на производительность.

Ровно то, что сказал, сказать и хотел. Еще раз: гхц ориентирован не только на производительность.

Ты ничего не сказал. Основная задача компилятора - переводить текст программы с языка в машинный/байт код. Если стандарт языка не меняется, то основное направление - улучшение главной функции, т.е. качества компиляции.

Молодец, ты на полпути к правильному выводу. А теперь вопрос: меняется ли стандарт Haskell, и меняется ли стандарт CL? Далее эти два ответа смиксовать, подумать и прочитать еще раз мой пост, который тебе так не понравился.

>Некоторые лисперы пытаются «примазаться» к популярности DSL и обосновать превосходство CL тем, что он якобы очень хорошо подходит для создания DSL. Но при этом, они отказываются как либо чётко определить, что же такое этот Domain Specific Language и используют его для описания всего подряд, тем самым искажая и обесценивая понятие DSL.

Это проблемы отдельных лисперов. Но CL позволяет определять «абстаркции» предметной области и манипуляции ими (в рамках s-expr) наиболее «естественным» для предметной области образом. И если лисп «такой навороченный», что только «супер-трансформация передаваемого кода» может послужить для придания статуса eDSL (при полной внешней однородности с прочим CL-кодом), то это говорит только о «развитости» CL и о том, что «настоящие eDSL» писать в нём в большинстве тривиальных случаев «излишне».

Т.е. фразу «очень хорошо подходит для создания DSL» нужно переписать как «очень хорошо подходит для работы с любой предметной областью, в большинстве случаев не требуя написания true-eDSL» - так?

> что далеко ходить — возьми анафорический if.

Можно более подробно раскрыть тему насколько широко используются анафорических макросы в коде проектов на CL?

Аналогично с любым макросом — использование

`(.. ,foo) или `(... foo)

Как это понимать? В чём заключается тонкость использования макросов вместе со стандартным синтаксисом backquote, имеющим совершенно чёткую семантику?

> Т.е. фразу «очень хорошо подходит для создания DSL» нужно переписать

как «очень хорошо подходит для работы с любой предметной областью,

в большинстве случаев не требуя написания true-eDSL» - так?

Абсолютно верно!

ну наконец-то пришли к консенсусу... =)

Молодец, ты на полпути к правильному выводу. А теперь вопрос: меняется ли стандарт Haskell, и меняется ли стандарт CL? Далее эти два ответа смиксовать, подумать и прочитать еще раз мой пост, который тебе так не понравился.

Объясни, к чему ты ляпнул: «Хаскельные компиляторы развиваются не только в сторону увеличения производительности. В отличии от того, что застряло в старом стандарте.» в ответ на сетование: «Разработчиков хаскеллевых компиляторов вообще нужно в угол поставить, что они до сих пор не всех подряд в клочья рвут.»?

Мне психоанализ твоим тараканам крайне обломно делать, чтобы понять их бредни.

>используйте штангу или что там вам по душе

Что, чуть пониже спины заболело?

>Что, чуть пониже спины заболело?

С моей стороны это было провокацией. Если ты «реагируешь» только на неё - болит как раз у тебя.

>> Аналогично с любым макросом — использование

`(.. ,foo) или `(... foo)

Как это понимать? В чём заключается тонкость использования макросов вместе со стандартным синтаксисом backquote, имеющим совершенно чёткую семантику?

Это так и понимать: ты под «семантическими расширениями» понимаешь непонятно что, например, синтаксический сахар. Сахар — это расширения, да, да только синтаксические, а не семантические. Семантические расширения — это способ задания новой операционной семантики, то есть, своего способа вычислений, например как eval: call-by-need, call-by-value, call-by-name;
например, переход с декларативного в функциональный/императивный; например, реализация пролога на лиспе.

Изобретать такие расширения в лиспе необходимости нет, в отличие от того же окамла, где написание dsl подразумевает написание своего гибкого eval — потому что уже стандартный синтаксис backquote с «ч0ткой семантикой» позволяет задать нужный порядок вычислений, то есть, операционную семантику, и переиспользовать стандартный eval там где порядка вычисления аргументов не хватает.

Вместе всё это составляет контрпример к твоему

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

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

Семантические расширения — это не когда можно описать :for foo :from 100 :to 1000 в eDSL, а когда способ вычисления этого for , eval его операционной семантики будет настолько суров, что его будет невозможно выразить стандартными средствами «из коробки», то есть стандартный read/eval + backquote.
Синтаксические расширения — это что ты пишешь iter или loop, for или какой там foreach.
А таких вариантов маловато: тот же :collecting запросто выражается. Вот termite наверно не выражается так просто, тут да, будут уже «семантические расширения» процесса вычисления. А для голимого loop/iter и сахарку хватит.

> Семантические расширения — это способ задания новой операционной

семантики, то есть, своего способа вычислений, например как eval:

call-by-need, call-by-value, call-by-name;

Лингвисты отчаянно протестуют!

Синтаксические расширения — это что ты пишешь iter или loop,

for или какой там foreach.

Разберитесь для начала в том, что такое язык, что такое лексические правила, что такое синтаксические правила и что такое семантические правила.

А почему бы не взять лисп, прикрутить к нему алгебраические типы данных, pattern matching, ленивость из коробки и прочие вкусности? Самое интересное, что всё это уже реализовано, Qi II называется, вот только судьба у него довольно печальна - умер так толком и не родившись. Вопрос: почему так?
P.S. Нет, мне действительно интересно.

Алсо сейчас существует возможность без особых трудностей перенести любой язык на jvm и .net (таким образом не нужны никакие либы), почему какое-никакое распространение получил только Clojure? Мне опять же сильно интересно, спрашиваю не троллинга ради.

> Qi II называется, вот только судьба у него довольно печальна

- умер так толком и не родившись. Вопрос: почему так?

Очевидно потому, что это оказалось никому не нужным.

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

Я когда-то подсчитал статистику редкого использоваия термина DSL в среде CL. http://www.linux.org.ru/jump-message.jsp?msgid=4911022&cid=5033388

> В общем, грань между DSL и API весьма условная.

Это условность проистекает искличительно из нечеткости и размытости определений DSL.

Если взять правильное определение имени меня :) то все сразу станет четким и ясным.

DSL - это язык который оперирует ИСКЛЮЧИТЕЛЬНО объектами предметной области.

Следствия:

Любая программа написаная на преметно-ориентированном языке понятна знакому с этой облатью без перевода и не требует знания других языков. Как пример SQL.

программа на eDSL может быть перенесен из одного языка в другой без изменений.

Используя это определение можно найти критерий различия API и DSL для одной и той же целевой предметной области (ПО). API в отличае от DSL выражен в терминах ПО языка реализации (переменных, типах, функциях, классах и.т.д) реализующих целевую ПО.

Отличный пост! Как-то я тот срач позабыл уже...

>> Да ты вообще любой макрос называешь DSL-ем

Не любой, а тот что имеет явный или неявный definition для семантики своих аргументов.

+1. Только надо учитывать неявную семантику backquote, в том числе

Например aif - просто макрос, там просто делается код в который подставляются аргументы (без вычисления).

Вот то, что аргументы — без вычисления, семантику и определяет. То есть, семантика макросов <> семантике функций. Если бы макросов не было в языке, потребовалось бы писать свой eval для макросов.

А вот в asdf или в defpackage макрос имеет стадию семантического анализа своего аргумента (того в котором все эти :depends-on и т.д.).

а тут уже определение операционной семантики языка похитрее чем стандартные макросы

а то, как именно определяется операционная семантика языка, через стандартные семантики макросов или функции — особого значения (для eval семантики идеально-сферичного языка) не имеет, но в the real word, например, оверхед может быть разный в compile time/run time

Это запрос SQL на языке F# (там своя собственная и непохожая версия Linq):

let res =
  query <@ seq { for emp in db.Employees do
                   if emp.BirthDate.Value.Year > 1960
                     && emp.LastName.StartsWith "S" then
                       yield (emp.FirstName, emp.LastName) }
           |> Seq.take 5 @>

Это транслируется в SQL запрос и затем выполняется. Возвращается последовательность пар. Самое интересное, что то, что находится внутри query <@ ... @> является полноценным выражением на F#. Если бы значение db.Employees означало бы не базу SQL, а нечто соответствующее, то это выражение даже можно было бы исполнить как обычное выражение на F#. То есть, с одной стороны эта штуковина выражена «в терминах ПО языка реализации» (c), а с другой - это просто по-другому записанный SQL.

К чему это отнести? К API или DSL?

> Я еще раз приведу язык 1C. Он позволяет оперировать объектами предметной области, но средства определения этих объектов в нем отсутствуют напрочь.
В нем вообще непримитивные типы отсутствуют напрочь!!!

это половые трудности конкретной реализации платформы конкретной реализации языка. Например, в 2С http://www.gpl2c.ru — GPL форке «проприетарной», но с открытыми исходниками 2С от vtools.ru В. Иванова — был реализован свой интерпретатор языка, являющегося надмножеством языка 1Сv7.

Там был реализован подход смоллтока: были уровень 0, уровень 1, уровень 2 «платформы», как метасистемы: каждый след. уровень был написан на предыдущем. Выглядело это так: уровень 0 — платформа и интерпретатор, уровень 1 — язык, совместимый с, с базовыми АТД «массив» и хеш-таблица, уровень 2 — язык, на котором описан базовый объект ТаблицаБД (любая SQL-таблица и СУБД API ), уровень 3 — реализация базовых объектов «справочник», документ, регистр на этом базовом ТаблицаБД

При всём при том, метапрограммирования не было, MFC был прикручен гвоздями к платформе, уровень 3 реализован наполовину и т.п. — но вполне таки работало, да..

Что не мешает описывать бизнес-логику очень нетривиальных ERP систем.

нетривиальных — мешает. Нерасширяемость языка, отсутствие слоёв, аспектов, событий (в v8 хоть с этим получше, но слои и метапрограммирование — всё ещё так же по нулям) — мешает.

Остаётся только то, что можно реализовать средствами API. Тот же пример с семёркой и 1С++ показывает, что полноценной интеграцией тут не светит, с сущностями первого порядка — облом, всё что не вписывается в API делается через ж.. или метапарсер (например, см. транслятор в 1С++ из неправильного SQL-я в «правильный»).

Остаётся только мечтать, что было бы возможно если был бы взят в руки нормальный язык с метапрограммированием... или хотя бы парсер + готовый метаязык.

Что я понимаю под слоями и полезным DSL, не API для этой задачи: это например, возможность описания бизнес-процесса и его логики, бизнес-логики как сущности первого порядка, в терминах IDEF0 (вход-выход-механизм-управление), в терминах BPML (карта бизнес-процесса), в терминах некоторых «сквозных» транзакций.
Например, процесс «продажа»: это отгрузка, реализация, выписка гарантийного талона и т.п. Отдельные подпроцессы-транзакции.
Подход/API/методология учёта в одноэсе: делаем по документу, фиксирующему выполнение очередной операции. В итоге обратные подпроцессы вроде отгрузка/приём, реализация/возврат, выписка/списание приходнится реализовывать по 2 раза в каждом фиксирующем документе.
Это наследие реализации платформы в стиле docflow, оно не сильно годится для упр. учёта (который не план-факт, а что-если), и планирования/перепланирования в том числе. Что произойдёт с событиями, кто должен их перезапускать?

Другой вопрос, если бы это было что-то типа BPML, только уровнем повыше, такой мета-BPML, написанный на себе самом. Из которого подпроцессы автоматом бы сверстались/разлились по слоям/docflow документам

То, что семантический уровень языка не описывается на нём самом в случае одноэса — довольно сильно мешает.

> То есть, с одной стороны эта штуковина выражена «в терминах ПО

языка реализации» (c), а с другой - это просто по-другому записанный

SQL.

Это просто часть платформы, к обсуждаемому вопросу отношения не имеет.

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

Ещё про нефритовый лингам напишите, Эзоп твою дивизию!!111

> Смысл DSL в том, что бы определить синтаксис, учитывающий специфику предметной области и так образом предоставить инструмент, упрощающий рассуждения о данной предметной области.

синтаксис?? бох с ним, с синтаксисом, всё равно всё закончится единым абстрактым сабжем в дереве AST

это просто вопрос удобства, не более. Сахарок-с.

а вот семантика — как раз и определяет специфику предметной области. Что вычисляется языком, как именно вычисляется, и как эти вычисления рассуждения о предметной области упрощають.

Ни о каком Domain Specific Language тут говорить нельзя.

можно. Ты упускаешь из виду то, как это всё будет исполняться. В том числе, твои воссторги по поводу CLOS это подтверждают. Было много бенчмарков с выводом вроде: ООП на структурах заметно быстрее ООП на CLOS+defclass+defgeneric.

вот как раз и просвети, чо такое эти «семантические правила». Что такое «операционная семантика языка» и «денотационная семантика языка» — это понятно. А откуда правила какие-то взялись? Из Розенталя?

Эти твои семантические правила и обычная операционная семантика — как сепульки и сепулькарии: ты определяешь одно через другое, и кажется, путаешь — где цель и замысел, а где — средства реализации

Лингвисты отчаянно протестуют!

лингвисты идут в сад осиливать управление по глаголу, 19 времён глаголов и склонения/спряжения в финском языке и прочие граммарнацности. Мы тут как бы не про любой язык, а про язык программирования, конкретно — про реализацию предметно-ориентированных языков на языках общего назначения.

> Любая программа написаная на преметно-ориентированном языке понятна знакому с этой облатью без перевода и не требует знания других языков. Как пример SQL

какой именно SQL возьмём: ANSI, T-SQL, PL-SQL, MySQL или SQLite SQL ? :))

программа на eDSL может быть перенесен из одного языка в другой без изменений.

то есть, я могу перенести eDSL на лиспе в SQL?

API в отличае от DSL выражен в терминах ПО языка реализации (переменных, типах, функциях, классах и.т.д) реализующих целевую ПО.

реализующих целевую — что ? — ПО? архитектуру?

DSL тоже реализует целевую — что, семантику? замысел? — ПО?

Часть этой платформы, называемая реализацией, имеет непосредственное отношение. Почему, ты думаешь, CLOS-ом так редко пользуются? Потому что бенчмарки, и внезапно ООП на defstruct-ах выходит быстрее ООП на defgeneric.
С точки зрения семантики, можыт быдь и не имеед. С точки зрения эффективности, способ реализации и метапрограммирование как частный случай реализаций — таки имеет значение.

> К чему это отнести? К API или DSL?

если бы там были иерархические группировки и итоги по ним, или вызов хранимок с интеграцией в Scala, я бы отнёс к DSL, ибо просто так в лоб на SQL они не реализуются, стало быть, нужно определять семантику, стало быть, DSL.
если бы простые какие-то трансформации, то скорее ближе к API.

> И где они сейчас? Где теперь некогда великий Watcom? Zortec, Borland и еще N штук?

разве что борман сдох? Watcom превратился в OpenWatcom, и в некотором роде жив ищщо. Zortech превратился в Symantec C++, который был (tm) + IDE поверх старого ядра, а ядром — Digital Mars C/C++ Волтера Брайта. Borland... хз что случилось с ним после версии 5.5-6.5, ибо в более поздних CxxBuilder был уже mingw

Кто сейчас генерирует более быстрый код из forte/msvc/icc/gcc?

icc 1 место / gcc /msvc делят 2 место, а вообще мерять надо

> Почему, ты думаешь, CLOS-ом так редко пользуются?

Чего? CLOS редко используется? Вы последние 10 лет вы в коме были?

Потому что бенчмарки, и внезапно ООП на defstruct-ах выходит

быстрее ООП на defgeneric.

И что бенчмарки? А ООП в С++ ещё быстрее, нет? Вы вообще в курсе, что такое defgeneric? Из активно развивающихся проектов defstruct кажется только в stumpwm активно используют, но он же г.. то ещё.

С точки зрения эффективности, способ реализации и

метапрограммирование как частный случай реализаций — таки

имеет значение.

Common Lisp выбирают не ради эффективности, так что эти соображения вообще не уместны для подавляющего большинства проектов.

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

Постулирую: изъян в твоей логике в том, что синтаксис и ясность языка — это цель и первично, а семантика языка, и механизмы её реализации — вторична и «ненужна» в некоторых способах реализации.
Во-первых, определение языка через семантику, а не синтаксис более полезно и конструктивно. К тому же, это совсем не больно, и достаточно готовых семантик вычислений/семантик макросов + управления eval-ом.
Во-вторых, эта семантика должна быть не очень сильно абстрактной, как любят давать штангисты в papers определения нового языка. А более конкретной, эффективной в реализации. То есть, эффективность реализации — одна из целей такой реализации семантики. Отсюда и трёхэтажное метапрограммирование, и контроль того, во что развернётся макрос с точки зрения эффективности построенного им кода.

> То есть, эффективность реализации — одна из целей такой реализации

семантики. Отсюда и трёхэтажное метапрограммирование, и контроль

того, во что развернётся макрос с точки зрения эффективности

построенного им кода.

Любезный, вы ничего не знаете о современном состоянии Common Lisp. Походите по проектам, посмотрите код.

> CLOS редко используется?

редко. Почему тогда каждый лепит свою ООП систему, в этом же должен быть какой-то смысл, цель?

вот, к примеру http://people.csail.mit.edu/gregs/ref-dyn-patterns.html http://people.csail.mit.edu/gregs/proglangsandsofteng_files/frame.htm

ну не просто так построенное ООП, а с целью — облегчить реализацию паттернов GoF

Код каких именно проектов наиболее интересен с точки зрения эффективной реализации выполнения DSL «платформы»? А то как раз вопрос эффективности реализации многие упускают из цели

> Почему тогда каждый лепит свою ООП систему, в этом же

должен быть какой-то смысл, цель?

Никто из людей занимающихся серьёзной разработкой на CL ничем подобным не занимается.

ну не просто так построенное ООП, а с целью — облегчить

реализацию паттернов GoF

Перестаньте народ смешить. Какие в ж... патерны GoF в CL? Кому эти костыли там сдались? Вообще маразм...

> Код каких именно проектов наиболее интересен с точки зрения

эффективной реализации выполнения DSL «платформы»?

Чего?

А то как раз вопрос эффективности реализации многие упускают из цели

Может просто не ставят такой цели?

> почему какое-никакое распространение получил только Clojure?

потому что jvm из коробки, очевидно же. Хотя есть kawa, и прочее.. да и виталиков MBase под .net работает, когда не валится какой-нибудь пример с ексепшнами под очередной версией .net, сломавшей совместимость с api

В этой связи любопытнее выглядит LLVM VMKit: http://vmkit.llvm.org/ http://vmkit.llvm.org/pubs.html http://vmkit.llvm.org/publications/vmkit.html