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

[Daniel Gackle]

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
:character-encoding :utf-8))

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."

Thanks again,
Daniel




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