Este é um pouco embaraçoso, mas estou preso nisso há mais tempo do que gostaria de admitir.
Gostaria de gerar uma macro que sombreie automaticamente um símbolo se ele for encontrado em algum pacote existente. Estou usando apenas o pacote :common-lisp e ocultarei várias funções do padrão.
Anteriormente, mantive uma lista de símbolos sombreados e exportados, mas gostaria de não manter essas listas. Em vez disso, eu preferiria sombrear o símbolo de uma macro, para poder ter a declaração de sombra e de exportação junto com a definição. Parece muito simples, entretanto, seja qual for a maneira que eu o implementei, ou estou violando os bloqueios de pacote, ou meu símbolo é indefinido, ou algo mais. Para começar, aqui está um pacote def:
(in-package :cl-user)
(uiop:define-package :foo-package
(:nicknames :foo)
(:use :common-lisp)
(:shadow #:defun))
(in-package :foo)
A função de teste não faz nada, apenas um pequeno wrapper para o teste:
(defun make-string (length init)
(cl:make-string length :initial-element init))
Minha primeira tentativa ficou assim:
(cl:defmacro defun (name arglist &optional docstring &rest body)
`(progn
(when (symbol-package ',name)
(shadow ',name))
(cl:defun ,name ,arglist ,docstring ,@body)
(export '(,name))))
No entanto, isso resulta em uma violação de bloqueio de pacote com SBCL, portanto, a função shadow obviamente não entra em vigor antes de eu tentar redefinir a função com cl:defun.
Envolvê-lo
(eval-when (:compile-toplevel :load-toplevel :execute)
para disponibilizá-lo em tempo de compilação não ajudou.
Outra tentativa foi usar um gerador:
(eval-when (:compile-toplevel :load-toplevel :execute)
(cl:defmacro defun (name args &optional docstring &rest body)
(macrolet ((export-it (name args &optional docstring &rest body)
`(progn
(when (symbol-package ',name)
(shadow ',name))
(cl:defun ,name ,args ,docstring ,@body)
(export '(,name) *package*))))
`(export-it ,name ,args ,docstring ,@body))))
Isso me dá common-lisp:make-string desvinculado:
depurador invocado em um UNBOUND-VARIABLE @10039FFD22 no thread #<THREAD "main thread" RUNNING {10044982F3}>: a variável MAKE-STRING não está associada.
Tentei gerar um lambda e funcall, mas também sem muito sucesso.
Se eu sombrear make-string manualmente de repl: (shadow 'make-string)
, posso posteriormente redefinir e exportar make-string sem problemas.
Parece que não entendi algo mais fundamental aí.
A propósito, eu estava lendo o artigo de M. Cracauer Compile Time Programming e achei uma boa ideia manter tudo no mesmo lugar, mas acho que minha familiaridade com macros e avaliação de tempo de compilação versus tempo de execução não é onde deveria estar .
Entendo que posso usar coisas específicas do SBCL para remover temporariamente bloqueios de pacotes, mas 'shadow' e 'symbol-package' ou 'find-package' e 'find-symbol' que usei inicialmente para verificar se um símbolo está internado em :common -lisp pacote, deve ser mais portátil.
Primeiro de tudo: nunca faça isso . Se eu tivesse projetado CL fazendo algo assim, resultaria na liberação no meio ambiente de uma quantidade de radioatividade grande o suficiente para garantir, sem sombra de dúvida, que répteis gigantes mutantes surgiriam de um oceano brilhante com radiação de Čerenkov e consumiriam toda a vida humana. Infelizmente, minhas sugestões nesse sentido foram rejeitadas pelo comitê de padrões.
Apenas... não faça isso. Se você deseja ter um pacote que redefina os nomes exportados pelo CL, defina o pacote desejado , não defina outro pacote e modifique-o gradativamente por formulários que obviamente nem sequer fazem alterações no sistema de pacotes.
Se você escrever um código que modifique o pacote (de maneiras não óbvias), você estará enfrentando sérios problemas.
Por um lado, você imediatamente terá problemas se usar
defpackage
ou qualquer coisa que se expanda paradefpackage
, porque a especificação diz:[Minha ênfase.]
E mesmo se você achar que está tudo bem, pense em algo assim
O que exatamente acontecerá quando esse código for processado pelo compilador? A primeira vez? Tempos subsequentes?
No final desta resposta há um adendo que descreve como você pode usar uma versão estendida
defpackage
para resolver o problema de uma forma que não faça com que monstros radioativos subam das profundezas.Mas aqui está a versão radioativa.
O que você deseja é que
(defun <name> ...)
, if<name>
seja um símbolo cujo pacote inicial não seja o pacote atual, em vez disso, organize para se referir a um novo símbolo com o mesmo nome, cujo pacote inicial seja o pacote atual e que esteja sombreando o símbolo original.Bem, na verdade você quer algo mais complicado do que isso, porque
<name>
pode ser(<setf> <s>)
, e talvez<setf>
não sejacl:setf
, mas apenas um símbolo cujo nome éSETF
.Aqui está uma definição inicial do pacote e
in-package
Aqui está uma função que faz essa sombra para você:
E aqui está uma versão
defun
que usa isso:Agora
Como evitar a criação de monstros.
Você pode fazer isso usando mecanismos CL comuns. Mas há vários calços
defpackage
que tornam isso mais fácil. Isso usa pacotes de conduíte porque estou familiarizado com eles. Acho que os ASDFdefine-package
também podem tornar isso muito fácil.Aqui está um pacote que exporta uma macro de definição de conduíte:
E agora
E
então o
my-non-radioactive-cl-variant
pacote agora é um pacote semelhante ao CL, exceto que alguns símbolos foram substituídos: você pode usá-lo em vez de CL (você não pode usá-lo com CL, pois ele exporta, por exemplo, um símbolo cujo nome é"DEFUN"
which é nãocl:defun
).E usando isso você tem um código que funciona e que pode ser lido facilmente.