From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Steve Yegge <stevey@google.com>
Cc: 6415@debbugs.gnu.org
Subject: bug#6415: [PATCH] fix edebug instrumentation of dotted pairs in macros
Date: Mon, 26 Sep 2011 21:43:46 -0400 [thread overview]
Message-ID: <jwvehz27oul.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <CAEYe22XLY0MYSSkxPrue0-m07rSxEx0teodgqiemuOKG+qmOvQ@mail.gmail.com> (Steve Yegge's message of "Mon, 26 Sep 2011 10:17:52 -0700")
> It so happens that the `cl-macro-list1' edebug-spec does all three
> of these things properly.
I haven't looked into it, so I'll trust on that one.
> The second problem is in edebug. The unification algorithm has
> improper or missing handling for dotted pairs in specs. I chose
> to add the handling to `edebug-match-specs' since it seemed to be
> the cleanest place to insert it.
This edebug-dotted-spec business is really ugly, I wonder if/how we
could just get rid of this variable. Or at least document clearly what
it is supposed to mean.
> - ;; Is the form dotted?
> - ((not (listp (edebug-cursor-expressions cursor)));; allow nil
> + ;; Special handling for the tail of a dotted form.
> + ((and
> + ;; Is the cursor on the tail of a dotted form?
> + (not (listp (edebug-cursor-expressions cursor)));; allow nil
> + ;; When matching a dotted form such as (a b . c) against a
> + ;; spec list that looks like
> + ;; ([&rest ...] [&optional ...]+ . [&or arg nil])
> + ;; ,e.g., the `cl-macro-list1' edebug-spec, then the &rest spec
> + ;; will consume everything up to the dotted tail (`c' in this
> + ;; example). At that point the spec list will look like so:
> + ;; ([&optional ...]+ . [&or arg nil])
> + ;; We need to be able to consume zero or more [&optional ...]
> + ;; spec(s) without moving the cursor or signaling an error.
> + ;; The current continuation provides no state that tells us
> + ;; about the upcoming &optional specs, so we use lookahead:
> +
> + ;; Recurse normally if we're about to process an optional spec.
> + (not (eq (car specs) '&optional))
> + ;; Recurse normally if the spec is a dotted list.
> + (not (and (listp specs)
> + (not (listp (cdr (last specs)))))))
> + ;; Otherwise we need to be on the tail of a dotted spec.
> (if (not edebug-dotted-spec)
> (edebug-no-match cursor "Dotted spec required."))
> ;; Cancel dotted spec and dotted form.
Questions:
- Should it really only be &optional? it looks like any &foo might work
just as well. Also shouldn't we check the (eq (aref (car specs) 0)
'&optional) instead?
- What's the purpose of the
(not (and (listp specs) (not (listp (cdr (last specs))))))?
For one (listp specs) will always be t (we've checked (atom specs)
earlier and we've just called (car specs) on the previous line)
so the code is really (not (and t (not (listp (cdr (last specs))))))
aka (listp (cdr (last specs))) but if the car of specs is not an
&optional, then we have a mismatch anyway, no?
Stefan
next prev parent reply other threads:[~2011-09-27 1:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-13 15:26 bug#6415: 23.1.50; edebug-eval-defun errors on dotted pair in some macros Geoff Gole
2011-09-26 17:17 ` bug#6415: [PATCH] fix edebug instrumentation of dotted pairs in macros Steve Yegge
2011-09-27 1:43 ` Stefan Monnier [this message]
2017-11-05 21:45 ` Gemini Lasswell
2017-11-26 23:02 ` Gemini Lasswell
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=jwvehz27oul.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=6415@debbugs.gnu.org \
--cc=stevey@google.com \
/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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
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).