Prev: the rise and fall of t
Next: emacs lisp tutorial: Count Words and Chars
From: Alan Malloy on 24 Mar 2010 20:48
Alberto Riva wrote:
> Alan Malloy wrote:
>> Alberto Riva wrote:
>>> Alan Malloy wrote:
>>>> By the way, I do understand the evaluation semantics; but I haven't
>>>> yet internalized them to the degree that I can produce code that
>>>> means what I want it to all the time. I tried macroexpand-1, too,
>>>> but I forgot I needed to quote the list so it was giving me the same
>>>> error. I was writing (macroexpand-1 (mymacro args)) instead of
>>>> (macroexpand-1 '(mymacro args))
>>>
>>> And do you understand why it gives you that error when you omit the
>>> quote?
>>>
>>> Alberto
>>
>> Yes. Without the quote it expands the macro and tries to execute it,
>> before macroexpand-1 can have a go at it (which, when my macro was
>> broken, caused an error). I assume this means macroexpand-1 is a
>> function, which surprised me, but I guess makes sense. I assumed it
>> would be a macro, in which case (I think?) it could intercept its
>> argument list coming in, and quote it before passing it to some
>> behind-the-scenes macro expander. I don't quite see why this isn't the
>> standard behavior for macroexpand-1, but I understand why, with the
>> function defined as it is, it behaves this way.
>
> Right. That's why I asked the question, I think it helps clarify the
> distinction between macroexpansion time and execution time. It seems you
> passed the test :)
>
> Alberto

Hah, yes and no. The difference between compile- and run-time is easy to
understand on paper, but I'm just glad you weren't there watching me
tear my hair out last night as I tried to figure out whether to put a
(let...) inside the backquote or outside it.

--
Cheers,
Alan (San Jose, California, USA)
From: Barry Margolin on 25 Mar 2010 00:27
In article <87ljdi0y5o.fsf(a)hangup.portland.xach.com>,
Zach Beane <xach(a)xach.com> wrote:

> Alan Malloy <alan.NO.SPAM(a)malloys.org> writes:
>
> > As mentioned earlier, I'm a new Lisper (and taking up emacs as well
> > now; thanks refun for re-suggesting it). I was trying to write a
> > simple macro earlier tonight, and I'd written a long post to ask
> > c.l.lisp to help me figure out what was wrong. But, afraid of looking
> > too much like a newcomer, I spent an additional hour or two trying to
> > understand what was happening and finally figured it out (so that's
> > good, I guess). My question NOW is, does anyone have a reference, or
> > even some general tips, on how to understand compiler/interpreter
> > error messages?
>
> Practice? The error message below immediately made me think "There's a
> bogus form that looks like ((setf ... nil) ...) somewhere." Maybe that's
> a matter of seeing similar errors like that in the past, and
> understanding the evaluations rules?

Furthermore, it's in a place where a function name is expected, since
the error message complained that it's not a function name. That's
usually the beginning of a list that's being evaluated.

>
> > Tonight's message was "EVAL: #1=(SETF #:G3813 NIL) is not a function
> > name; try using a symbol instead", and it took me forever to
> > understand that I was misusing backquote as `((setf ,var nil) (more
> > stuff) when what I really meant was `(progn (setf ,var nil) (more
> > stuff).
>
> Practice will help with that, too.
>
> Zach

--
Barry Margolin, barmar(a)alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
First  |  Prev  | 
Pages: 1 2 3
Prev: the rise and fall of t
Next: emacs lisp tutorial: Count Words and Chars