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

Daniel Gackle danielgackle at gmail.com
Thu May 21 00:29:52 PDT 2009


< Did you LOAD the file that contains your macro definition? >

Yes, along with a bunch of files that use the macro, all of which work fine.
It's only the REPL access that's problematic (plus C-c C-c to compile an
individual defun), as I described.

Perhaps I should mention that there are other macros defined in the same
file, none of which exhibit the symptoms of the λ one; they all macroexpand
properly in the REPL and so on. And if I change the name of the troublesome
macro from λ to something like FOO, it too becomes well-behaved.

Daniel

On Thu, May 21, 2009 at 1:12 AM, R. Matthew Emerson <rme at clozure.com> wrote:

>
> 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?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20090521/44eef8df/attachment.htm>


More information about the Openmcl-devel mailing list