help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Evaluation of macro arguments


From: Marcin Borkowski
Subject: Re: Evaluation of macro arguments
Date: Thu, 14 Jan 2016 21:32:07 +0100
User-agent: mu4e 0.9.13; emacs 25.1.50.1

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
basically instantaneously).

>>> 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
>> smoothly.
>
> 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.

;-)

>         Stefan

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.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University



reply via email to

[Prev in Thread] Current Thread [Next in Thread]