< Did you LOAD the file that contains your macro definition? ><br><br>
Yes, along with a bunch of files that use the macro, all of which work
fine. It's only the REPL access that's problematic (plus C-c C-c to
compile an individual defun), as I described.<br>
<br>
Perhaps I should mention that there are other macros defined in the
same file, none of which exhibit the symptoms of the ë one; they all
macroexpand properly in the REPL and so on. And if I change the name of the troublesome macro from ë to something like FOO, it too becomes well-behaved.<br>
<br>
Daniel<br><br><div class="gmail_quote">On Thu, May 21, 2009 at 1:12 AM, R. Matthew Emerson <span dir="ltr"><<a href="mailto:rme@clozure.com">rme@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;">
<div class="im"><br>
On May 21, 2009, at 2:44 AM, Daniel Gackle wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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,<br>
<br>
(defun foo ()<br>
(ë (x) (1+ x)))<br>
<br>
works the way you'd expect if you compile the file it's in. But in the REPL bad things happen:<br>
<br>
(defun foo ()<br>
(ë (x) (1+ x)))<br>
;Compiler warnings :<br>
; In FOO: Undefined function Ë<br>
; In FOO: Undefined function X<br>
; In FOO: Undeclared free variable X<br>
=> FOO<br>
</blockquote>
<br></div>
Did you LOAD the file that contains your macro definition?<br>
<br>
In SBCL, if you run compile-file on a file that defines a macro, that macro definition appears to get added to the global environment as a side-effect. This doesn't happen in CCL (that's a feature).<br>
<br>
For example, create /tmp/foo.lisp:<br>
<br>
(in-package "CL-USER")<br>
<br>
(defmacro junk (arg)<br>
`(format t "~s" ,arg))<br>
<br>
In SBCL:<br>
<br>
* (compile-file "/tmp/foo")<br>
<br>
; compiling file "/tmp/foo.lisp" (written 21 MAY 2009 02:59:24 AM):<br>
; compiling (IN-PACKAGE "CL-USER")<br>
; compiling (DEFMACRO JUNK ...)<br>
<br>
; /tmp/foo.fasl written<br>
; compilation finished in 0:00:00<br>
#P"/tmp/foo.fasl"<br>
NIL<br>
NIL<br>
* (macroexpand '(junk 12))<br>
<br>
(FORMAT T "~s" 12)<br>
T<br>
*<br>
<br>
In CCL:<br>
? (compile-file "/tmp/foo")<br>
#P"/private/tmp/foo.dx32fsl"<br>
NIL<br>
NIL<br>
? (macroexpand '(junk 12))<br>
(JUNK 12)<br>
NIL<br>
? (load "/tmp/foo")<br>
#P"/private/tmp/foo.dx32fsl"<br>
? (macroexpand '(junk 12))<br>
(FORMAT T "~s" 12)<br>
T<div><div></div><div class="h5"><br>
?<br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
(foo)<br>
=> Undefined function X called with arguments () .<br>
[Condition of type CCL::UNDEFINED-FUNCTION-CALL]<br>
<br>
(macroexpand '(ë (x) (1+ x)))<br>
=> (Ë (X) (1+ X))<br>
<br>
And if you use slime-compile-defun on the (defun foo...) form, the following 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 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?<br>
</blockquote>
<br>
</div></div></blockquote></div><br>