Thanks to everyone who responded. We fixed the problem by putting the following in .ccl-init.lisp:<br><br>  (setf ccl:*default-external-format* (ccl:make-external-format :character-encoding :utf-8))<br><br>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.)"<br>

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

<br>Thanks again,<br>Daniel<br><br><br><br><br><div class="gmail_quote">On Thu, May 21, 2009 at 2:47 AM, Gary Byers <span dir="ltr"><<a href="mailto:gb@clozure.com">gb@clozure.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

What character encoding is Slime using to talk to the lisp ?<br>
<br>
If you do:<br>
<br>
SLIME-PROMPT> (defvar *string* "<lambda>")<br>
<br>
where <lambda> is a single #\u+03bb character, what do:<br>
<br>
SLIME-PROMPT> (length *string*)  ; should be 1<br>
<br>
and<br>
<br>
SLIME-PROMPT> (char-code (schar *string* 0)) ; should be #x3bb = 955.<br>
<br>
return ?<br>
<br>
If Slime thinks that the stream used to talk to CCL is UTF-8 encoded<br>
and CCL thinks that it's encoded in ISO-8859-1, Slime would send two<br>
bytes (#xce #xbb), which the lisp would interpret as two 8-bit<br>
ISO-8859-1 character codes (for the characters<br>
#\Latin_Capital_Letter_I_With_Circumflex and<br>
#\Right-Pointing_Double_Angle_Quotation_Mark.)<br>
<br>
After starting to write this reply, I looked at your message in a mail<br>
client that's more Unicode-aware than the one that I usually use.  It<br>
looked like the lisp had uppercased the lambda character at some point,<br>
which suggests that the lisp and Slime agree on the character encoding.<br>
<br>
If the problem here isn't something more mundane (like the symbol whose<br>
name is the LAMBDA character not being visible in the REPL's package),<br>
I wonder if something similar happened when the file containing the<br>
macro definition was compiled.  E.g., the lambda character would be<br>
encoded in those two bytes in a UTF-8-encoded file, but if the file was<br>
compiled with a default :EXTERNAL-FORMAT of :ISO-8859-1, a two-character<br>
symbol name  would have been read and interned and defined as a macro.<br>
(That would have happened consistently, so calls to the macro in the<br>
file(s) would appear to work as expected.)<br>
<br>
If this or something like it turns out to be the problem, I vote that<br>
the entire world stop using 8-bit character encodings and immediately<br>
encode all existing and future files, web pages, email messages, etc.<br>
in UTF-32 whose endianness matches whatever computer I'm using at the<br>
moment.<br>
<br>
CCL's reader treats (almost) all non-ASCII characters as "constituents"<br>
(characters that can form symbols) and this shouldn't be sensitive to<br>
what kind of stream the characters are being read from.  (The character<br>
encoding of that stream affects the sequence of characters that the<br>
reader sees, and this sounds like it may be a case where an encoding<br>
was incorrectly specified.)<div class="im"><br>
<br>
On Thu, 21 May 2009, Daniel Gackle wrote:<br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
We defined a macro named ë (Greek lambda character, in case this email isn't<br>
Unicode-friendly) to expand into a lambda form, partly to save typing and<br>
partly to add a couple extra features our system needs. This works fine when<br>
you compile files, but not in a Slime REPL or when using the command<br>
slime-compile-defun. For example,<br>
<br>
(defun foo ()<br></div>
 (ë (x) (1+ x)))<div class="im"><br>
<br>
works the way you'd expect if you compile the file it's in. But in the REPL<br>
bad things happen:<br>
<br>
(defun foo ()<br></div>
  (ë (x) (1+ x)))<br>
;Compiler warnings :<br>
;   In FOO: Undefined function Ë<br>
;   In FOO: Undefined function X<div class="im"><br>
;   In FOO: Undeclared free variable X<br>
=> FOO<br>
<br>
(foo)<br>
=> Undefined function X called with arguments () .<br>
  [Condition of type CCL::UNDEFINED-FUNCTION-CALL]<br>
<br></div>
(macroexpand '(ë (x) (1+ x)))<br>
=> (Ë (X) (1+ X))<div class="im"><br>
<br>
And if you use slime-compile-defun on the (defun foo...) form, the following<br>
occurs:<br>
<br>
While compiling FOO :<br>
#1=(X) is not a symbol or lambda expression in the form (#1# (1+ X)) .<br>
  [Condition of type CCL::COMPILE-TIME-PROGRAM-ERROR]<br>
<br>
I'm posting this here because none of the above errors happen in SBCL, so<br>
there would seem to be something specific about the combination of Slime and<br>
CCL that doesn't like this macro. Does anyone have any ideas or suggestions?<br>
<br>
</div></blockquote>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Thank you,<br>
<br>
Daniel Gackle<br>
</blockquote>
</blockquote></div><br>