From: Paul Eggert <eggert@cs.ucla.edu>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>, emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] master b7fa6b1 1/4: Simplify use of FOR_EACH_TAIL
Date: Sun, 5 Feb 2017 21:23:43 -0800 [thread overview]
Message-ID: <e98e1e76-6564-535c-72b0-2b08aa3d7eb6@cs.ucla.edu> (raw)
In-Reply-To: <jwvwpd43yno.fsf-monnier+emacsdiffs@gnu.org>
Stefan Monnier wrote:
> I'm surprised you
> also decided to remove `tail`, since that one *is* used by the users of
> the macro and forcing them to use `li.tail` instead of the variable of
> their choice is rather odd.
Logically, the variable is part of the iterator, not of the surrounding code. I
did at first write a macro along the lines that you suggest, and also tried
another variant where the user could specify a name of their choice for the
iterator, but in both cases this extra flexibility made the code a bit more
verbose and was not that useful in practice. It would be easy to resurrect this
flexibility if needed (it doesn't affect efficiency, of course).
Here's an example. At first, I wrote a revised version like this:
Lisp_Object tail;
FOR_EACH_TAIL (tail, list)
if (EQ (XCAR (tail), elt))
return true;
but this was annoying both because the user must declare 'tail', and because
typically 'tail' should not survive the loop but the declaration forces it to
survive. I wanted something more like this:
FOR_EACH_TAIL (tail, list)
if (EQ (XCAR (tail), elt))
return true;
where the macro declares 'tail' to be local to the loop. Unfortunately there
doesn't seem to be any way to that in portable C. So I settled for this:
FOR_EACH_TAIL (list)
if (EQ (XCAR (li.tail), elt))
return true;
which is even shorter than what I wanted, albeit with an 'li.tail' that looks
odd at least at first. Although we could easily change things to let the caller
specify a name, like this:
FOR_EACH_TAIL (li, list)
if (EQ (XCAR (li.tail), elt))
return true;
it's rare to need different names for iterators, so it's unclear that this extra
complexity would be helpful.
next prev parent reply other threads:[~2017-02-06 5:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20170205213033.19755.8264@vcs.savannah.gnu.org>
[not found] ` <20170205213034.20306220171@vcs.savannah.gnu.org>
2017-02-06 1:19 ` [Emacs-diffs] master b7fa6b1 1/4: Simplify use of FOR_EACH_TAIL Stefan Monnier
2017-02-06 5:23 ` Paul Eggert [this message]
2017-02-06 15:37 ` Eli Zaretskii
2017-02-07 1:35 ` Paul Eggert
2017-02-07 15:32 ` Eli Zaretskii
2017-02-06 17:38 ` Davis Herring
2017-02-07 1:04 ` Paul Eggert
2017-02-07 20:45 ` Johan Bockgård
2017-02-07 21:50 ` Richard Stallman
2017-02-07 22:18 ` Paul Eggert
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=e98e1e76-6564-535c-72b0-2b08aa3d7eb6@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=emacs-devel@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.
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).