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

[Gary Byers]

What character encoding is Slime using to talk to the lisp ?

If you do:

SLIME-PROMPT> (defvar *string* "<lambda>")

where <lambda> is a single #\u+03bb character, what do:

SLIME-PROMPT> (length *string*)  ; should be 1

and

SLIME-PROMPT> (char-code (schar *string* 0)) ; should be #x3bb = 955.

return ?

If Slime thinks that the stream used to talk to CCL is UTF-8 encoded
and CCL thinks that it's encoded in ISO-8859-1, Slime would send two
bytes (#xce #xbb), which the lisp would interpret as two 8-bit
ISO-8859-1 character codes (for the characters
#\Latin_Capital_Letter_I_With_Circumflex and
#\Right-Pointing_Double_Angle_Quotation_Mark.)

After starting to write this reply, I looked at your message in a mail
client that's more Unicode-aware than the one that I usually use.  It
looked like the lisp had uppercased the lambda character at some point,
which suggests that the lisp and Slime agree on the character encoding.

If the problem here isn't something more mundane (like the symbol whose
name is the LAMBDA character not being visible in the REPL's package),
I wonder if something similar happened when the file containing the
macro definition was compiled.  E.g., the lambda character would be
encoded in those two bytes in a UTF-8-encoded file, but if the file was
compiled with a default :EXTERNAL-FORMAT of :ISO-8859-1, a two-character
symbol name  would have been read and interned and defined as a macro.
(That would have happened consistently, so calls to the macro in the
file(s) would appear to work as expected.)

If this or something like it turns out to be the problem, I vote that
the entire world stop using 8-bit character encodings and immediately
encode all existing and future files, web pages, email messages, etc.
in UTF-32 whose endianness matches whatever computer I'm using at the
moment.

CCL's reader treats (almost) all non-ASCII characters as "constituents"
(characters that can form symbols) and this shouldn't be sensitive to
what kind of stream the characters are being read from.  (The character
encoding of that stream affects the sequence of characters that the
reader sees, and this sounds like it may be a case where an encoding
was incorrectly specified.)

On Thu, 21 May 2009, 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
>
> (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?
>


> Thank you,
>
> Daniel Gackle
>