unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Marcin Borkowski <mbork@mbork.pl>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: help-gnu-emacs@gnu.org
Subject: Re: Evaluation of macro arguments
Date: Thu, 14 Jan 2016 21:32:07 +0100	[thread overview]
Message-ID: <87io2vewc8.fsf@mbork.pl> (raw)
In-Reply-To: <jwvegdkwa6y.fsf-monnier+Inbox@gnu.org>


On 2016-01-14, at 14:47, Stefan Monnier <monnier@iro.umontreal.ca> 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	other threads:[~2016-01-14 20:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-05 10:59 Evaluation of macro arguments Marcin Borkowski
2016-01-05 12:55 ` Stefan Monnier
2016-01-13 22:16   ` Marcin Borkowski
2016-01-14 13:47     ` Stefan Monnier
2016-01-14 20:32       ` Marcin Borkowski [this message]
2016-01-14 23:05         ` Stefan Monnier
2016-01-05 19:22 ` Pascal J. Bourguignon
2016-01-05 19:39   ` Marcin Borkowski
2016-01-05 20:30     ` Marcin Borkowski
     [not found]     ` <mailman.1794.1452025850.843.help-gnu-emacs@gnu.org>
2016-01-08 23:13       ` duthen.mac.01

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87io2vewc8.fsf@mbork.pl \
    --to=mbork@mbork.pl \
    --cc=help-gnu-emacs@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).