[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Evaluation of macro arguments
Re: Evaluation of macro arguments
Thu, 14 Jan 2016 21:32:07 +0100
mu4e 0.9.13; emacs 126.96.36.199
On 2016-01-14, at 14:47, Stefan Monnier <address@hidden> wrote:
>> I still don't get it. If it's not checked while edebugging, what's the
>> point of the precise declaration?
> It's *used* (rather than checked) when *setting up* the Edebug
> instrumentation, rather than while single stepping through the code.
> [ I realize now that maybe "setup edebug instrumentation" is what you
> meant by "edebugging", while to me "edebugging" means something more
> like single-stepping, which is what happens after the instrumentation
> has been put in place. ]
Well, it turns out that I was quite confused. Now that you wrote it, it
does make perfect sense; in my experiments with this issue
I instrumented single forms to be evaluated and not defuns, so (as you
wrote below) there was no observable difference (both steps happened
>>> Instead, such a precise Edebug spec would cause an error (and not
>>> a very pretty one) when you ask Edebug to annotate the code).
>>> I'd use a spec like (declare (debug (form symbolp form))).
>> I tried it and did not get any error message. Why? More precisely,
>> here's what I have done:
>> --8<---------------cut here---------------start------------->8---
>> (defun upto-or-downto-p (symbol)
>> (memq symbol '(upto downto)))
>> (defmacro range (from dir to)
>> "Return a list of numbers starting with FROM and going up to
>> TO-1 if DIR is the symbol 'upto or down to TO+1 if DIR is the
>> symbol 'downto. Warning: this version is broken!"
>> (declare (debug (form upto-or-downto-p form)))
>> `(let ((delta (cond ((eq ',dir 'upto) 1)
>> ((eq ',dir 'downto) -1)))
>> (i ,from)
>> (list nil))
>> (while (not (= i ,to))
>> (push i list)
>> (setq i (+ i delta)))
>> (nreverse list)))
>> (range (- 5 4) upto (+ 4 6))
>> --8<---------------cut here---------------end--------------->8---
>> Then I pressed C-u C-M-x on the last form, and everything went
> Yes, that's normal.
I would hope so! ;-)
>> If I replace 'upto with something else, I get this:
>> edebug-syntax-error: Invalid read syntax: upto-or-downto-p, "failed"
> That's the error I was referring to (and indeed, if the code is right
> you should not be getting an error). The error can become more
> troublesome for more complex Edebug specs where Edebug can try various
> alternatives in which case the error you get may be about an alternative
> which shouldn't have been tried anyway.
Ah, so it has something to do with those &or, &and etc.? I have to
admit that I did not really understand that part of the manual. I will
try to understand it some day (sooner than later, I hope). It would be
great if I managed to come up with a patch for the manual then to make
it easier for future generations. ;-)
Are there any worthy examples of edebug specs in Emacs sources? (I
could just grep for them - and I'll probably do that anyway - but if
somebody could point me to some of those which are especially suitable
for understanding the thing, it would be great. Of course, I will start
with the examples provided in the manual.)
> To see the difference between "instrumentation" and "single-stepping",
> you need to try C-u C-M-x on something like
> (defun my-foo () (range (- 5 4) typo (+ 4 6)))
> where you'll immediately get the error during C-u C-M-x rather than latr
> on when you call my-foo.
Makes sense, especially that (in my macro) the upto/downto has to sit
right there in the code (I mean, literally - it cannot be the result of
any evaluation, since that argument of my macro is never evaluated!)
>> So basically it seems that I was (more or less) right. OTOH, I can't
>> be right about anything Emacs-related and you be wrong on it, so what's
>> going on?
> I think we were just in violent agreement.
Thanks for your patience! I'm slowly learning this stuff, and I hope to
"pay back" to the community by at least writing a blog post, and maybe
a patch for the manual.
Faculty of Mathematics and Computer Science
Adam Mickiewicz University
Re: Evaluation of macro arguments, Pascal J. Bourguignon, 2016/01/05