Итого, это можно сделать через member или через satisfies (который будет по сути member item list, только list будет дополняться). Но тут большой вопрос, зачем. Потому что это правда эксперимент на уровне около компилятора по сути, и выглядит так, что тут лучше CLOS.

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

И можно определить для них предикат и им одним обойтись.

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

Я просто еще не понимаю как в принципе в  CL (sbcl) работают типы и ассерты. сбцл кидает иногда ворнинги типа "у тебя на месте, где эта функция ждет список, стоит байда, осторожней!"

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

Выставить (declare (type list x)) где x это аргумент.

Помимо этого могут быть нужны optimize декларации. У меня в шаблоне проекта системы есть

(asdf:defsystem
    ..
    :around-compile
  (lambda (next)
    (proclaim '(optimize 
  (compilation-speed 0)
                (debug 3)
                (safety 3)
                (space 0)
                (speed 0)))
    (funcall next))
  ..)

так что SBCL максимально жесток.

Спасибо!

Ну вообще это стремно выглядит. То есть, там define-my-dlambda, и оно пихает свежесозданную функцию в список всех наших функций. В определении типа будет либо satisfies my-dlambda-p, а my-dlambda-p проверяет на принадлежность глобально определенному списку (по eq), либо в определении типа будет (member ,@dlambdas), и тогда это определение (типа!) каждый раз перевычисляется внутри define-my-dlambda.

Я не интересовался, каковы гарантии динамического переопределения типов в CL. Но из общих соображений понятно, что тут мало на что можно рассчитывать. Если пойти путем satisfies, то предупреждения о том, что my-dlambda не попало в какой-то аргумент, почти наверняка будут появляться без каких-то проблем, но никакого inference не будет.

На Emacs Lisp я пишу часто, чтобы помогать себе в повседневных делах. На Common Lisp такого нет, потому что нету среды типа Emacs. Люди, которые используют stumpwm, скорее всего будут писать себе что-то повседневное на CL. Я не использую stumpwm, но пишу один патч, который внесет для меня CL в список языков, помогающих в повседневных делах.

Это как это "динамического переопределения типов" ?

Как бы если они там переопределяются, то типа просто нет... Или он более широкий.

Обращаю внимание, что в CLOS MOP есть funcallable objects, и это выглядит более разумно. См. например обсуждение на точно такую же тему: https://stackoverflow.com/questions/27558980

Я даже не удивлюсь, если это в итоге будет работать. Но рассчитывать не стал бы, и не удивлюсь если и не будет. :-) Надо смотреть, что написано в спецификации.

так не будешь включать оптимизацию -- и вообще ВСЁ будет работать!

Если не включать оптимизацию, то снова встает вопрос, почему для идентификации dlambda предлагается использовать тип, а не класс.

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

Я не понимаю ни одного слова, что ты тут написал...

В смысле слова понимаю, смысл -- нет.

Странно; я очень хорошо и понятно пишу. Но я переписал.

Если серьезно, то люди на это мне жалуются в последнее время. Буду следить.

Так и есть, повседневное для stumpwm. Плюс пилю свой грааль который должен помочь в академии неслабо.

Алсо радует наличие (возможность создания) тонких клиентов для всяких гнутых утилит типа гнуплота. И сравнительная легковесность сбцл. Результат: можно быстро вкорячить условного бота для телеги на raspberry.