[Openmcl-devel] Macro named λ won't expand in Slime REPL

[R. Matthew Emerson]

On May 21, 2009, at 2:44 AM, Daniel Gackle wrote:

> We defined a macro named λ (Greek lambda character, in case this  
> email isn't Unicode-friendly) to expand into a lambda form, partly  
> to save typing and partly to add a couple extra features our system  
> needs. This works fine when you compile files, but not in a Slime  
> REPL or when using the command slime-compile-defun. For example,
>
> (defun foo ()
>   (λ (x) (1+ x)))
>
> works the way you'd expect if you compile the file it's in. But in  
> the REPL bad things happen:
>
> (defun foo ()
>    (λ (x) (1+ x)))
> ;Compiler warnings :
> ;   In FOO: Undefined function Λ
> ;   In FOO: Undefined function X
> ;   In FOO: Undeclared free variable X
> => FOO

Did you LOAD the file that contains your macro definition?

In SBCL, if you run compile-file on a file that defines a macro, that  
macro definition appears to get added to the global environment as a  
side-effect.  This doesn't happen in CCL (that's a feature).

For example, create /tmp/foo.lisp:

(in-package "CL-USER")

(defmacro junk (arg)
   `(format t "~s" ,arg))

In SBCL:

* (compile-file "/tmp/foo")

; compiling file "/tmp/foo.lisp" (written 21 MAY 2009 02:59:24 AM):
; compiling (IN-PACKAGE "CL-USER")
; compiling (DEFMACRO JUNK ...)

; /tmp/foo.fasl written
; compilation finished in 0:00:00
#P"/tmp/foo.fasl"
NIL
NIL
* (macroexpand '(junk 12))

(FORMAT T "~s" 12)
T
*

In CCL:
? (compile-file "/tmp/foo")
#P"/private/tmp/foo.dx32fsl"
NIL
NIL
? (macroexpand '(junk 12))
(JUNK 12)
NIL
? (load "/tmp/foo")
#P"/private/tmp/foo.dx32fsl"
? (macroexpand '(junk 12))
(FORMAT T "~s" 12)
T
?


> (foo)
> => Undefined function X called with arguments () .
>    [Condition of type CCL::UNDEFINED-FUNCTION-CALL]
>
> (macroexpand '(λ (x) (1+ x)))
>  => (Λ (X) (1+ X))
>
> And if you use slime-compile-defun on the (defun foo...) form, the  
> following occurs:
>
> While compiling FOO :
> #1=(X) is not a symbol or lambda expression in the form (#1# (1+ X)) .
>    [Condition of type CCL::COMPILE-TIME-PROGRAM-ERROR]
>
> I'm posting this here because none of the above errors happen in  
> SBCL, so there would seem to be something specific about the  
> combination of Slime and CCL that doesn't like this macro. Does  
> anyone have any ideas or suggestions?