[Openmcl-devel] Macro named λ won't expand in Slime REPL
danielgackle at gmail.com
Thu May 21 09:43:55 PDT 2009
Thanks to everyone who responded. We fixed the problem by putting the
following in .ccl-init.lisp:
(setf ccl:*default-external-format* (ccl:make-external-format
I believe Gary's explanation was correct: "the lambda character [was]
encoded in ... 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.)"
It's worth mentioning that *default-external-format* has to be set before
starting Slime, which makes me think that Tobias' suggestion is a good idea:
"Perhaps Slime should send the buffer's coding-system with each request, and
we should pass that over to COMPILE-FILE."
On Thu, May 21, 2009 at 2:47 AM, Gary Byers <gb at clozure.com> wrote:
> 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
> 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
> 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
> 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
>> 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
>> 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
>> 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
>> => 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
>> 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
>> CCL that doesn't like this macro. Does anyone have any ideas or
> Thank you,
>> Daniel Gackle
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openmcl-devel