[Openmcl-devel] Macro named λ won't expand in Slime REPL
gb at clozure.com
Thu May 21 04:34:56 PDT 2009
On Thu, 21 May 2009, Tobias C. Rittweiler wrote:
> Gary Byers <gb at clozure.com> writes:
>> 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, ...
> The problem is not that the network stream is in the wrong encoding
> because the encoding, usually, comes from Emacs. That's also the reason
> that it'll work when you type in everything at the REPL.
Daniel actually said that his code didn't work in the REPL, but as noted
later in my reply the fact that the lisp uppercased the lambda character
suggests that Slime and CCL agree on the encoding of the network stream.
He said that it worked as expected when he compiled and loaded a file
containing the macro definition, but this may have worked correctly
while misinterpeting the two octets used to encode the lambda character
as two ISO-8859-1 character codes. (Or something like that: some discrepancy
between the file's actual encoding and the :EXTERNAL-FORMAT used by
> I think, the problem is that the file is encoded in utf8, but an
> :EXTERNAL-FORMAT of :DEFAULT in COMPILE-FILE is not utf8 in CCL as far
> as I can see. (In SBCL :DEFAULT is utf8 if unicode-enabled.)
In CCL, :DEFAULT uses a user-settable value that's initially equivalent
to :ISO-8859-1; since it's user-settable, passing an explicit :EXTERNAL-FORMAT
as you suggest seems wise.
> Perhaps Slime should send the buffer's coding-system with each request,
> and we should pass that over to COMPILE-FILE.
> Helmut, are you reading this list?
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel