Martin Buchholz wrote:
EXTERNAL_LIST_LOOP_2(elt, list)
used to require that the user declare elt and list.
After Ben's recent changes to the LIST_LOOP macros, the macro itself
declares elt. I think this is a mistake and propose reversion.
This is a similar issue to the question of how long the scope of an
identifier declared in a `for' initializer lasts in C++ or C99.
Some users of EXTERNAL_LIST_LOOP_2 may want to use the value of elt
after the loop has exited. And there are other reasons why the user
may want a different scope for elt.
One could provide two versions of EXTERNAL_LIST_LOOP_*, but I think it
is clearly not worth the confusion. The saving of one declaration
Lisp_Object elt;
is not worth the loss of flexibility and increase in magicality.
Ohhhhhh, I see now Ben *has* created _NO_DECLARE versions of these
macros. I think this is very subtle and confusing.
EXTERNAL_LIST_LOOP_2_NO_DECLARE declares *some* of the variables, but
not all. The name suggests to me "No Declarations At All", and I was
suprised to discover it does some of them *and* still requires the
added braces. I think this is too subtle a distinction and propose
reversion to the old interface, and removal of all the _NO_DECLARE
macros.
martin, what are you smoking? as i read through your diatribe here, the idea
that _NO_DECLARE should indeed not declare any of its variables is the only
thing i agreed with. but i could have sworn that i did indeed do this -- and i
did!
there is no EXTERNAL_LIST_LOOP_2_NO_DECLARE.
the docs for EXTERNAL_LIST_LOOP_4_NO_DECLARE read
EXTERNAL_LIST_LOOP_4_NO_DECLARE is like EXTERNAL_LIST_LOOP_4 but none
of the variables are automatically declared, and so you need to declare
them yourself. (ELT and TAIL are Lisp_Objects, and LEN is an EMACS_INT.)
go look at the source.
With my previous implementation of these macros, it was very simple
for the user to know which variables had to be declared - all the
variables mentioned in the macro call had to be declared. This makes
the use of these macros somewhat less magical. There's still the
magic of having to provide a { } block around the call, but that seems
unavoidable, and the compiler error in case of a mistake means that no
subtle bugs will be introduced.
This issue is similar in spirit to the TO_EXTERNAL_FORMAT debate. I
want to avoid a proliferation of APIs that cause confusion for the
maintainers. Both of these changes have confused *me*, the original
implementor - I now feel less sure when using these macros.
Martin
--
Ben
In order to save my hands, I am cutting back on my mail. I also write
as succinctly as possible -- please don't be offended. If you send me
mail, you _will_ get a response, but please be patient, especially for
XEmacs-related mail. If you need an immediate response and it is not
apparent in your message, please say so. Thanks for your understanding.
See also
http://www.666.com/ben/chronic-pain/