Штука даже не в том что я знаю плохо все тонкости clos, а в том, что первый лисповый подход нагляднее: сам стейт наружу не торчит, labels задают мини-язык доступа к нему, вся дефиниция в несколько строк.

Если тут нет больших подводных камней - юзать и радоваться.

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

Оптимизировать тут явно есть что, например.

Ну и напомню: если юзер не в курсе имплементации, и что-то пойдет не так, то ошибка часто ничего ему не скажет, а может, и имплементатору не скажет если много времени прошло. А CLOS это протокол со стандартизованными ошибками.

Например, там где CLOS скажет

The function
 #<STANDARD-GENERIC-FUNCTION APPLICATION::BLAH (1)>
requires at least 2 arguments.
  [Condition of type SB-INT:SIMPLE-PROGRAM-ERROR]

dlambda скажет

invalid number of arguments: 1
  [Condition of type SB-INT:SIMPLE-PROGRAM-ERROR]
...
Backtrace:
 0: ((LAMBDA ()) T) [external]
     [No Locals]

(no locals это если скомпилировано с установками по умолчанию)

Это просто первое что мне пришло в голову. Но вообще я и сам люблю навернуть лямбдочку, да и все.

Ок, понял. Тут такая динамика что надо быть осторожным.
Ожирению dlambda-ов буду препятствовать принципиально: жирнеть планируют менеджеры их создающие, потому что в @body будут писаться разные комбинации subprocess-вызовов. Но сами ламбдочки останутся такими вот стройными.

Надо добавить gensym'ы, не cons'ить лишнего в t и убрать quote

...и это в т.ч. главный аргумент против соседей, у которых как раз в этом месте 30 этажей ооп-абстракций (не юзабельно ваще, дебажить тоже bольно)

Большое спасибо за разбор!

пипец у вас тут разбор

я начинаю бояться борща

Не бойся

Я танцую от Питмана http://www.nhplace.com/kent/PS/Lambda.html

Для меня Лисп это идея, что между компьютером и его юзером не должно быть препятствий. Гомоиконность, мощные макросы, интерактивность, мультипарадигменность по-моему вытекают из этого. Из этого вытекает и что лица, принимающие решения, не должны ставить препятствий между юзерами и их компьютерами, типа «надо запретить мутабельность» или «мощные макросы это проблема, требующая решения».

Гомоиконность, пожалуй, не вытекает непосредственно из идеи. Но она вытекает из требования мощных макросов, которое вытекает из идеи.

Прозрачные основания Лиспа, т.е. возможность легко определить Лисп в своих терминах, вытекают из необходимости понимать *произвольные* алгоритмы, описывать их и манипулировать ими. Думаю, тут существенна вся совокупность этих трех требований. Каждое из них по отдельности вытекает из исходной идеи. Макросы тоже вытекают из совокупности этих трех требований, но на месте макросов теоретически могли бы быть и fexpr'ы. Но если вывод, к которому пришло Лисп-сообщество «fexpr'ы невозможно эффективно компилировать», правильный, то макросы лучше соответствуют идее.

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

cons это по сути просто «упорядоченная пара». В математике это понятие вводится и начинает активно использоваться очень быстро, но оно все же не фундаментальное. Фундаментальное это «множество»; множества не упорядочены, имеют много (в т.ч. бесконечно много) элементов. Короче, множества не очень хорошая фундаментальная абстракция для описания алгоритмов; «упорядоченная пара», очевидно, отличная абстракция. Я использовал гомоиконный язык, который пошел скорее по стопам APL, так что там не было cons, а были только (многомерные, вообще говоря) массивы, и идиомы строились вокруг них. Это было неплохо, но нехватку cons я ощутил довольно быстро. В итоге я думаю, cons это не случайность, но все-таки cons, наверное, не вытекает из идеи «между компьютером и его юзером не должно быть препятствий», просто мы пока не используем (не можем себе представить?) компьютеры, где cons было бы субоптимальным вариантом. В принципе, это же относится и к макросам, в сравнении с fexpr'ами.

> Фундаментальное это «множество»
не факт. также не факт что множества появились раньше упорядоченных пар

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

когда ищешь основания математики приходится придумывать как выразить уже существующие понятия в терминах этих оснований

@akater  а как кст
запретить setf слоты

чтоб даже через slot-value