Вышел новый релиз реализации языка Common Lisp - Clozure CL 1.5

> HTML & ODF тоже DSL

И эти люди рассуждают о DSL? И PNG это, конечно, тоже DSL?

> DSL подразумевает декларативность прежде всего.

скорее нет, чем да

декларативность сюда (к еДСЛ-ям) затесалась по той причине, что по-настоящему декларативные конструкции требуют такой обработки компилятором хост-языка, которой обычно не предусмотрено

например, мы хотим сделать свой switch с банановым вкусом (с константными строками-образцам), при этом сделать оптимизацию: если один образец является начальной подстрокой другого, то повторно совпадение не проверяется; я не знаю, как такое сделать в скале (и думаю, что невозможно)

> И PNG это, конечно, тоже DSL?

да,

и вполне реально, что кому-то захочется реализовать его как embedded DSL

>> И PNG это, конечно, тоже DSL?

да

Ну тогда и JPEG тоже DSL. И gif DSL, и формат документов MS Office это тоже DSL, и BMP если внимательно присмотреться - тоже DSL.

Хватит курить траву, вредно для здоровья...

> Да точно нет, как ни смотри, ибо это просто формат, как и HTML.
формат ? - а почему не декларация (уже упамянутая) или спецификация

то какая из лисп библиотек лучше, чем аналогичные возможности lxml (python)?

смотря что считать лучше, если гибкость то однозначно лисп хоть с либой из pcl, если нужен готовый набор фичастых кубиков то mainstream рулит, а lisp еще пока не совсем, смотря что пишем и надолго ли

А вот это совершенно не понятно,

тогда так, представь что описываеш внешний DSL, а потом когда опишеш просто добавь скобочек :) кстати верно и обратное, если из примера на сайте cl-pdf выкинуть скобочки и прочее второстепенное появится текст понятный даже некоторым продвинутым полиграфистам

PostScript, XSLT или там awk. И между этими примерами достаточно легко можно обнаружить общность, что это именно DSL

а можно сформулировать общность PostScript и XSLT

Но кроме «макросов» другой общности мне увидеть не удаётся.

и даже макросов может и не быть, не то что преобразований

И опять таки, если полезность внешних DSL хорошо известна и доказана практикой, то на каких основаниях можно судить о пользе eDSL совершенно не ясно.

а чем по сути так отличаются внешние и внутренние DSL, кроме аспектов реализации, тем более с точки зрения полезности ? к тому же последние куда мощнее за счет возможности взаимной интеграции ...

>> Наличие выделенного этапа трансляции eDSL -> host language.

Выглядит убедительно, но можно практический пример?

Простейший пример - мaкрос ford, который дал Саныч (это такой примитивный eDSL из одной конструкции). Добавить в него проверку границ, чтобы он генерировал пустой оператор, если границы равны - будет настоящий транслятор :)

cl-who, пожалуй делает нечто подобное

В CL не разбираюсь вообще.

> Зачем тогда вообще отдельно упоминать об этом eDSL? Если его не отличишь от обычного api?

а тут смотря как определить API, в моем понимании API это foo_create_node(FOO_X) и foo_set_attribute(FOO_A,«b»), при этом:

1. все очень длинно

2. компилятор не замечает имя атрибута с опечаткой

3. компилятор не замечает несовместимого набора атрибутов

4. IDE не делает completion

в хорошо сделанном eDSL все наоборот

на самом деле перечень явно не полный...

> формат ? - а почему не декларация (уже упамянутая) или спецификация

Если говорить правильно, то язык разметки, на который есть спецификация.

если нужен готовый набор фичастых кубиков то mainstream рулит

Да при чём тут mainstream? Я имел в виду конкретно это решение: http://codespeak.net/lxml/tutorial.html#the-e-factory

если из примера на сайте cl-pdf выкинуть скобочки и прочее

второстепенное появится текст понятный даже некоторым продвинутым

полиграфистам

Гы ))) Ты вообще когда-нибудь читал спецификацию на PDF? а на PostScript? А с cl-pdf много работал? Подозреваю элементарную инженерную неграмотность.

а можно сформулировать общность PostScript и XSLT

Это специализированные языки программирования. На них можно программировать, но эффективно только в рамках предметной области.

а чем по сути так отличаются внешние и внутренние DSL, кроме

аспектов реализации, тем более с точки зрения полезности ?

Не знаю, я хочу увидеть пример хорошего eDSL, но мне его не показывают :(

> а тут смотря как определить API, в моем понимании API это

foo_create_node(FOO_X) и foo_set_attribute(FOO_A,«b»), при этом:

В таком случае, библиотека lxml (http://codespeak.net/lxml/) является примером DSL?

> Простейший пример - мaкрос ford, который дал Саныч

Это просто макрос. Хорош язык с одной конструкцией и без определённого domain.

А cl-pdf просто библиотека, api для генерации pdf, почему стоит причислять её к eDSL мне не понятно.

я склонен cl-pdf отнести к api (а что там по моим пунктам 2,3,4?)

вот хорошая тема для обсуждения: как должен выглядеть этот фрагмент кода в eDSL

(pdf:with-document ()
   (pdf:with-page ()
     (let ((helvetica (make-instance 'pdf:font)))
       (pdf:add-fonts-to-page helvetica)
       (pdf:in-text-mode
         (pdf:set-font helvetica 36.0)
         (pdf:move-text 100 800)
         (pdf:draw-text "CL-PDF: Example 1"))
       (pdf:translate 230 500)
       (loop repeat 101
         for i = 0.67 then (* i 1.045)
         do (pdf:in-text-mode
           (pdf:set-font helvetica i)
           (pdf:move-text (* i 3) 0)
           (pdf:draw-text "rotation"))
         (pdf:rotate 18))))
   (pdf:write-document #P"ex1.pdf"))

И вопрос: pdf:with-document и pdf:with-page работают лексически или динамически? Т.е. если вдруг внутри мы вызовем функцию, которая (неожиданно) тоже создает пдф-документ, она будет писать в тот же документ на ту же страницу?

>> Простейший пример - мaкрос ford, который дал Саныч

Это просто макрос

Это просто пример.

Хорош язык с одной конструкцией и без определённого domain.

Его domain - генерация циклов :)

> И вопрос: pdf:with-document и pdf:with-page работают лексически

или динамически?

Эти макросы просто настраивают динамические переменные *document* и *page* (про динамические переменные можно почитать здесь: http://lisper.ru/articles/cl-vars), плюс with-page проводит финализацию страницы, по сути, они аналогичны макросу with-open-file, просто работают с другими объектами. Какой-либо обработки кода (&body) внутри макроса не производиться, он вызывается как есть (обратный пример можно посмотреть в упоминавшейся cl-who, в которой тело макроса обрабатывается специальным образом). Так же и макрос in-text-mode, просто настраивает динамическое окружение.

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

> неявные параметры передавать можно и нужно лексически (это даже ява

позволяет, правда, видимо, с ограничениями), а динамические

переменные это дурной тон...

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

их же компилятор не может отследить

И чё? Common Lisp вообще-то язык динамический...

> И чё? Common Lisp вообще-то язык динамический...

затруднено программирование в функциональном стиле

например, необходимо читать из входного потока команды на запись и параллельно (но в рамках одной нити) писать в 10 страниц одной пдф-ки

функционально было бы сделать массив, положить туда 10 замыканий; каждому замыканию на вход подается команда, оно что-то пишет на свою страницу и возвращает новое замыкание (либо нил, если команда была закончить работу)

можно ли обернуть (не переписать) этот код во что-то, чтобы

1. страница и документ сохранялись в замыканиях?

2. этот код нормально работал в параллельно исполняемых нитях?

> В таком случае, библиотека lxml (http://codespeak.net/lxml/) является примером DSL?

х.з., бегло глянул — кажется что апи

> затруднено программирование в функциональном стиле

ничего, это мы переживём ;)

страница и документ сохранялись в замыканиях?

Можно. Только зачем?

этот код нормально работал в параллельно исполняемых нитях?

Я использую cl-pdf на стороне веб-сервера во время обработки запросов. Никаких проблем с параллельным исполнением. Кажется ты не понял, что такое динамические переменные ;)

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

* вычислено

> в хорошо сделанном eDSL все что может быть вычеслено во

время компиляции вычисляется именно тогда

Тогда я вообще не знаю примера eDSL для Common Lisp. Наверное на Common Lisp не пишут eDSL.

> Я использую cl-pdf на стороне веб-сервера во время обработки запросов. Никаких проблем с параллельным исполнением. Кажется ты не понял, что такое динамические переменные ;)

твой веб-сервер работает на нитях или форкается?

и да, я не знаю, может в CL придумали thread-local по умолчанию для лексических переменных

> твой веб-сервер работает на нитях

на нитях.

и да, я не знаю, может в CL придумали thread-local по умолчанию

для лексических переменных

В CL придумали динамические переменные.

я уж заговариваться стал, для динамических конечно

так вот я не знаю, как динамические переменные взаимодействуют с нитями; с замыканиями они взаимодействуют хреново, а вот для нитей язык может и костыль подставить

> Хм, а ODT это тоже DSL??

ты путаешь теплое с мягким, ODT — формат хранения данных, для HTML формат данных — plain text.

> с замыканиями они взаимодействуют хреново

в чем проявляется хреновость?

Почувствуй разницу между лексичекскими (AKA полными) и динамическими замыканиями.

> ты путаешь теплое с мягким, ODT — формат хранения данных,

для HTML формат данных — plain text.

Пойди почитай что такое ODT

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

> в чем проявляется хреновость?

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

ну и доступ к ним думаю помедленнее, чем к локальным переменным

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

тогда объясни: вот порядок выполнения:

Thread 1                              Thread 2
(pdf:with-document ()
   ...                                (pdf:with-document ()
   ...                                   ...
   (pdf:write-document #P"1.pdf"))       ...
                                         (pdf:write-document #P"2.pdf"))

с динамическими переменными окажется, что нить 2 запишет файл 1.pdf, нет? если нет, то почему?

> динамические переменные хреновы не сами по себе,

а как средства передачи значения по умолчанию

Они играют роль неявных параметров, а не значений по-умолчанию.

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

Сферические замыкания в вакууме?

ну и доступ к ним думаю помедленнее, чем к локальным переменным

Конечно, но это того стоят.

> с динамическими переменными окажется, что нить 2 запишет файл 1.pdf,

нет? если нет, то почему?

Нет, конечно. Связывание динамических переменных с новыми значениями производится (обычно, и конкретно в with-document) с помощью формы let и это связывание имеет действие только для вложенного в let кода, так требует стандарт языка.

> Связывание динамических переменных с новыми значениями производится (обычно, и конкретно в with-document) с помощью формы let и это связывание имеет действие только для вложенного в let кода

Вопрос был в том, относится ли имя *document* к разным переменным.

> Вопрос был в том, относится ли имя *document* к разным переменным.

Конечно.

> Пойди почитай что такое ODT

дай ссылку

> Почувствуй разницу между лексичекскими (AKA полными) и динамическими замыканиями.

при чем тут разность? кто Вам запрещает делать лексические замыкания, когда они Вам нужны и динамические когда они Вам нужны? вопрос был «в чем хреновость»? не нужно — юзай лексические

> Нет, конечно. Связывание динамических переменных с новыми значениями производится (обычно, и конкретно в with-document) с помощью формы let и это связывание имеет действие только для вложенного в let кода, так требует стандарт языка.

кстати, для LispWorks'ного CAPI это не работает. это как-то связано с CFFI?

> Сферические замыкания в вакууме?

вполне практические сценарии развития проекта и практические задачи, одну я уже кратко описал

да и вообще все ООП возникло в значительной степени как способ лексически передавать неявные параметры — значит задач хватает

> да и вообще все ООП возникло в значительной степени как способ

лексически передавать неявные параметры

В Simula то? Опять что-то курим? ;) Вообще знакомая песня, чую хаскелиста :)) Смысл ООП в определённом подходе к декомпозиции задачи, а не «способе лексически передавать неявные параметры», тем более, что такое вряд ли можно сказать о реализации ООП в Common Lisp.

> кстати, для LispWorks'ного CAPI это не работает. это как-то

связано с CFFI?

Без понятия о чём ты, у меня нет LispWorks (я запустил его один раз, ужаснулся и больше делать этого не стал) и я не работал с CAPI.

>> Вопрос был в том, относится ли имя *document* к разным переменным.

Конечно.

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

> Вообще знакомая песня, чую хаскелиста :))

не угадал — хаскель мне тоже не нравится

> а что делать, если нам нужны неявные аргументы, читаемые и

записываемые двумя разными нитями?

Не пойму, ты про использование глобальных переменных? Тогда нам нужны мьютексы и т.п. Или про что? В Hunchentoot для каждого запроса создаются объекты request и reply, которые связываются с динамическими переменными *request* и *reply*, какие-либо конфликты исключены, каждый потоки спокойно работают каждый со своей версией привязки.

Короче, приведи какой-нибудь реалистичный пример, а то я не понимаю.

завтра напишу

> Если говорить правильно, то язык разметки, на который есть спецификация.
это был наводящий вопрос

Да при чём тут mainstream? Я имел в виду конкретно это решение: http://codespeak.net/lxml/tutorial.html#the-e-factory

я же написал про библиотеку из pcl, даже там в последнем варианте есть compile-time оптимизация статических строк, и где это в lxml ? или макро-систему лиспа можно применять поверх той html библиотеки.
про mainstream я написал потому что даже не смотря на эту разницу lxml все равно полезен в определенных задачах. И твой вопрос в лоб что лучше - не состоятелен, если ты опять не понял

Гы ))) Ты вообще когда-нибудь читал спецификацию на PDF? а на PostScript? А с cl-pdf много работал? Подозреваю элементарную инженерную неграмотность.

жену свою подозревай :) есть что сказать - говори, изображать тут не надо, еще и по Мартину поясни за одно

Это специализированные языки программирования.

а на iterate совсем нельзя программировать в рамках ее предметной области ?

Не знаю, я хочу увидеть пример хорошего eDSL, но мне его не показывают :(

eDSL-и в этом не виноваты :) если такие проблемы возьми тоже же XLST и переложи синтаксис на лисп максимально близко, только потом не говори что это просто набор макр. :) затем задай вопрос чем это принципиально отличается от iterate

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

нет никаких проблем

(defvar *default-foo* 123) ; так переменная глобальна для всех нитей, доступ через mutex

(defun func-foo (&optional (foo *default-foo*)) ; dynamic -> lexical local
#'(lambda () (print foo)))

; в Thread X

(funcall (func-foo)) ; 123


(let ((*default-foo* 321)) ; теперь и внутри *default-foo* другая динамическая переменная = 321, только для thread X
(funcall (func-foo)) ; 321
)

(funcall (let ((*default-foo* 321)) (func-foo))) ; 321

в случае если действительно нужен конкурентный доступ из разных тредов, тогда в func-foo береш значение с with-lock-held

> кстати, для LispWorks'ного CAPI это не работает. это как-то связано с CFFI?
код покажи

> Ну разве не идиот? Идиот, причем клинический. Такой бред человек с мозгом писать не стал бы.

Дети бушуют. Весна.