Почему CLISP не может вызывать определенные функции с неинтернированными именами?

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

Если бы вы имели в виду сам символ, все, что вам нужно было бы сделать при реализации lisp, — это найти symbol-function этого символа. Интернирован он или нет, не имеет значения.

Могу я спросить, почему вы не рассмотрели другой способ скрыть функции, то есть оператор labels или определение функций в новом пакете, который экспортирует только одну внешнюю функцию?

EDIT: следующий пример буквально скопирован из взаимодействия с подсказкой CLISP.

Как видите, вызов функции, названной gensym, работает, как и ожидалось.

[1]> (defmacro test ()
(let ((name (gensym)))
`(progn
(defun ,name () (format t "Hello!"))
(,name))))
TEST
[2]> (test)
Hello!
NIL

Может быть, ваш код, который пытается вызвать функцию, оценивается до defun? Если в расширении макроса есть какой-либо код, кроме различных defun, это может зависеть от реализации, что будет оцениваться первым, и поэтому поведение SBCL и CLISP может отличаться, и ни один из них не нарушает стандарт.

РЕДАКТИРОВАНИЕ 2. Некоторые дальнейшие исследования показывают, что поведение CLISP зависит от того, интерпретируется ли код напрямую или сначала компилируется, а затем интерпретируется. Вы можете увидеть разницу, либо непосредственно load создавая файл Lisp в CLISP, либо сначала вызывая compile-file для него, а затем load создавая FASL.

Вы можете увидеть, что происходит, взглянув на первый перезапуск, который предлагает CLISP. Он говорит что-то вроде «Введите значение, которое будет использоваться вместо (FDEFINITION '#: G3219)». Таким образом, для скомпилированного кода CLISP заключает символ в кавычки и обращается к нему по имени.

Однако кажется, что это поведение соответствует стандарту. Следующее определение можно найти в HyperSpec:

обозначение функции n. обозначение функции; то есть объект, который обозначает функцию и является одним из: символа (обозначающего функцию, названную этим символом в глобальной среде) или функции (обозначающей саму себя). Последствия не определены, если символ используется в качестве обозначения функции, но не имеет глобального определения в качестве функции или имеет глобальное определение в виде макроса или специальной формы. См. также обозначение расширенной функции.

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

EDIT 3: (Я могу согласиться с тем, что я не уверен, является ли поведение CLISP ошибкой или нет. Об этом должен судить кто-то, более опытный в деталях терминологии стандарта. Все сводится к тому, является ли функциональная ячейка неинтернированного символа — т. е. символа, на который нельзя ссылаться по имени, только имея прямое удержание объекта символа — будет считаться «глобальным определением» или нет)

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

(defmacro test ()
  (let* ((pkg (make-package (gensym)))
         (name (intern (symbol-name (gensym)) pkg)))
    `(progn
       (defun ,name () (format t "Hello!"))
       (,name))))

(test)

EDIT 4: Как отмечает Джошуа Тейлор в комментарии к вопросу, похоже, это случай (10-летнего) ошибка CLISP №180.

Я проверил оба обходных пути, предложенных в этом отчете об ошибке, и обнаружил, что замена progn на locally на самом деле не помогает, но замена на let () помогает.

Вы наверняка можете определить функции, имена которых являются неинтернированными символами. Например:

CL-USER> (defun #:foo (x)
           (list x))
#:FOO
CL-USER> (defparameter *name-of-function* *)
*NAME-OF-FUNCTION*
CL-USER> *name-of-function*
#:FOO
CL-USER> (funcall *name-of-function* 3)
(3)

Однако синтаксис резкое двоеточие вводит новый символ каждый раз, когда такая форма читается читается:

#: вводит неинтернированный символ с именем имя-символа. Каждый раз, когда встречается этот синтаксис, создается отдельный неинтернированный символ. Имя символа должно иметь синтаксис символа без префикса пакета.

Это означает, что даже если что-то вроде

CL-USER> (list '#:foo '#:foo)
;=> (#:FOO #:FOO) 

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

CL-USER> (eq '#:foo '#:foo)
NIL

Это означает, что если вы попытаетесь вызвать такую ​​функцию, набрав #:, а затем имя символа, именующего функцию, у вас возникнут проблемы:

CL-USER> (#:foo 3)
; undefined function #:foo error

Итак, хотя вы можете вызвать функцию, используя что-то вроде первого примера, который я привел, вы не можете сделать последний. Это может немного сбивать с толку, потому что печатное представление выглядит так, как будто это происходит. Например, вы можете написать такую ​​факториальную функцию следующим образом:

(defun #1=#:fact (n &optional (acc 1))
  (if (zerop n) acc
      (#1# (1- n) (* acc n))))

используя специальные обозначения для чтения #1=#:fact и #1#, чтобы позже ссылаться на тот же символ. Однако посмотрите, что происходит, когда вы печатаете ту же форму:

CL-USER> (pprint '(defun #1=#:fact (n &optional (acc 1))
                    (if (zerop n) acc
                        (#1# (1- n) (* acc n)))))

(DEFUN #:FACT (N &OPTIONAL (ACC 1))
  (IF (ZEROP N)
      ACC
      (#:FACT (1- N) (* ACC N))))

Если вы возьмете этот распечатанный вывод и попытаетесь скопировать и вставить его как определение, читатель создаст два символа с именем «ФАКТ», когда дело доходит до двух вхождений #:FACT, и функция не будет работать (и вы даже можете получить предупреждения о неопределенных функциях):

CL-USER> (DEFUN #:FACT (N &OPTIONAL (ACC 1))
           (IF (ZEROP N)
               ACC
               (#:FACT (1- N) (* ACC N))))

; in: DEFUN #:FACT
;     (#:FACT (1- N) (* ACC N))
; 
; caught STYLE-WARNING:
;   undefined function: #:FACT
; 
; compilation unit finished
;   Undefined function:
;     #:FACT
;   caught 1 STYLE-WARNING condition

Надеюсь, я правильно понял задачу. Для меня это работает в CLISP.

Я пробовал так: используя макрос для создания функции с именем GENSYM-ed.

(defmacro test ()  
  (let ((name (gensym)))  
    `(progn  
       (defun ,name (x) (* x x))  
       ',name)))

Теперь я могу получить имя (setf x (test)) и назвать его (funcall x 2).

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

Вам нужно будет сохранить неинтернированный символ в какой-то структуре данных, чтобы затем иметь возможность получить символ. В качестве альтернативы сохраните определенную функцию в какой-либо структуре данных.

Удивительно, но ошибка CLISP 180 на самом деле не является ошибкой соответствия ANSI CL. Не только это, очевидно, что ANSI Common Lisp сам по себе настолько сломан в этом отношении, что даже обходной путь, основанный на progn, является любезностью реализации.

Common Lisp — это язык, предназначенный для компиляции, и компиляция вызывает проблемы с идентификацией объектов, которые помещаются в скомпилированные файлы и загружаются позже («внешние» объекты). ANSI Common Lisp требует, чтобы литеральные объекты, воспроизведенные из скомпилированных файлов, были только похожи на исходные объекты. (CLHS 3.2.4 Буквальные объекты в скомпилированных файлах).

Во-первых, в соответствии с определением подобия (3.2.4.2.2 Определение подобия), правило для неинтернированных символов заключается в том, что сходство основано на имени. Если мы скомпилируем код с литералом, который содержит неинтернированный символ, то при загрузке скомпилированного файла мы получим похожий символ, а не (обязательно) тот же объект: символ с тем же именем.

Что, если один и тот же неинтернированный символ будет вставлен в две разные формы верхнего уровня, которые затем будут скомпилированы в виде файла? Когда файл загружается, эти два хотя бы похожи друг на друга? Нет, такого требования нет.

Но становится еще хуже: также не требуется, чтобы два экземпляра одного и того же неинтернированного символа в одной и той же форме были экстернализированы таким образом, чтобы сохранялась их относительная идентичность: чтобы повторно загруженная версия этот объект будет иметь один и тот же объект символа во всех местах, где был оригинал. На самом деле определение сходства не содержит положений о сохранении круговой структуры и совместного использования подструктур. Если у нас есть такой литерал, как '#1=(a b . #1#), как литерал в скомпилированном файле, кажется, не требуется, чтобы он был воспроизведен как круговой объект с той же структурой графа, что и оригинал (изоморфизм графа). Правило подобия для минусов задается как наивная рекурсия: два минуса подобны, если их соответствующие car и cdr подобны. (Правило не может быть выполнено даже для круглых объектов, оно не завершается).

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

Таким образом, чисто согласно ANSI CL мы не можем рассчитывать на использование макросов с gensyms в скомпилированных файлах, по крайней мере, в некоторых случаях. Ожидание, выраженное в коде, подобном следующему, противоречит спецификации:

(defmacro foo (arg)
   (let ((g (gensym))
         (literal '(blah ,g ,g ,arg)))
      ...))

(defun bar ()
  (foo 42))

Функция bar содержит литерал с двумя вставками gensym, которые, согласно правилам подобия для cons и символов, не должны воспроизводиться как список, содержащий два вхождения одного и того же объекта на второй и третьей позициях.

Если приведенное выше работает должным образом, это связано с «расширениями правил сходства».

Таким образом, ответ на вопрос "Почему CLISP не может..." заключается в том, что, хотя CLISP предоставляет расширение для подобия, которое сохраняет структуру графа литеральных форм, оно не делает этого во всем скомпилированном файле, а только в пределах отдельных элементы верхнего уровня в этом файле. (Он использует *print-circle* для выделения отдельных элементов.) Ошибка в том, что CLISP не соответствует наилучшему возможному поведению, которое могут себе представить пользователи, или, по крайней мере, лучшему поведению, демонстрируемому другими реализациями.