Re: AC_FOREACH public?

[Keith MARSHALL]

Stepan Kasal wrote, quoting me:
>> I *like* autoconf, but, if I have one harsh criticism, it is that 
>> perfectly good macro names are deprecated much too frequently.
>
> Yes, I miss AC_TRY_COMPILE and friends.  Unfortunately, since the new
> interface is (subtly) different, it was necessary to find another name.

I agree, of course, that when the API changes it is necessary to change
the name;  but, as a replacement for AC_TRY_COMPILE, AC_COMPILE_IFELSE
is still definitively an *autoconf* macro.

> If a macro has nothing to do with Autoconf, it is just a feature
> of the macro language, then it should be named m4_*
> This is the case of m4_include, m4_if, m4_define and such.

This is an esoteric distinction, which may seem important to you as a
developer, but has little, if indeed any relevance to the user, IMHO.
As developers, (and I include myself here, having contributed code to
groff and to MinGW), we often take such decisions without adequate
consideration of the users' perspective, whereas *really* we should
attach paramount importance to how the user will perceive the issue,
(and I confess that I too have been guilty of ignoring this tenet).

However, I am not an autoconf developer; I am merely a user.  So,
indulge me please, and allow me to offer a user's perspective --
specifically, from *this* user's point of view.

When I write my configure.ac, aclocal.m4, or acinclude.m4, *every*
macro I use is, from my perspective, an *autoconf* macro.  That some
of these are called AC_*, AS_*, m4_*, or indeed anything else, is
not important to me -- they are still *autoconf* macros.  That these
naming conventions have some deep significance for you, as a developer,
is irrelevant to me, as a user -- indeed, they contribute only to
generating a potential mish-mash of confusion.

> And this is the case of AC_FOREACH; if you write
>
> AC_FOREACH([Boy], [Saul Fred Orrie], [Hi, Boy!
> ])
>
> you get
>
> Hi, Saul!
> Hi, Fred!
> Hi, Orrie!
>
> this is just a macro feature.  It has nothing to do with shell
> scripting nor with "configure script generation".

Granted, this is true;  but when you use this in an autoconf script,
you implicitly place it into an autoconf context, and autoconf *does*
have *everything* to do with "configure script generation", for that
is autoconf's "raison d'être".

> So AC_FOREACH is not a good name.

I would respectfully disagree -- IMO, it's a perfectly good name for
any macro, to be used in any autoconf context, which implements a
`foreach' construct.

> ...  But, of course, that is not reason to touch it.  But:
>
>> If the previous AC_FOREACH implementation is flawed, then by all
>> means reimplement it the way this silly thing does, but keep the
>> elegant name
>
> But what if the interface is broken?  There is no way to add
>
>        Hi, Paul, my dear!
>
> to the above loop--the string contains spaces.  m4_foreach is much
> better:
>
> m4_foreach([Boy], [Saul, Fred, Orrie], [Hi, Boy!
> ])
> m4_foreach([Boy], [[Saul], [Fred], [Orrie], [Paul, my dear]],
> [Hi, Boy!
> ])
>
> The first call is equivalent to the previous example.  The second
> one is fully quoted and shows that members can contain spaces and
> commas.

That's a different issue.  Actually, I would again respectfully
disagree that the interface is broken -- it merely suffers from some
limitations.  The right, and proper thing to do, IMO, is to document
it, pointing out those limitations, and illustrating the alternative,
using m4_foreach, for those cases where it may be more appropriate.

> So I believe that in most cases it is better to use m4_foreach
> instead of AC_FOREACH.  Actually, in a private discussion Ralf
> admitted that a comma separated list (so called "m4 list") might be
> better for his application.
>
> So I'm more and more convinced that the "Foreach" node in Autoconf
> manual should first describe m4_foreach and recommend it.

Certainly, m4_foreach needs to be documented;  but does AC_FOREACH
need to be deprecated?  You could equally well keep it, and document
*both*, perhaps even noting that, of the two, m4_foreach *may* be
the preferred choice, in most situations.

> Then it would document m4_split and say: "If, for some reason, you
> have to process a whitespace-separated list, you can use this
> pattern:
>       m4_foreach([Var], m4_split(m4_normalize([$1]), [...Var...])
> supposing that $1 contains the list.

But now you are saying "Perhaps you do need AC_FOREACH, but I've
killed it, so you will have to use this more complex construct
instead".  Or, you implement your `m4_foreach_w', (to which you
referred in a previous posting), and which is really just AC_FOREACH
by a different name -- more user confusion.  Ugh.

> m4_normalize has to be documented, too, perhaps in another section,
> say "text manipulation".  The m4_bpatsubst could go there, too.
> (It's not a redefined builtin, so there is no reason why it should
> be in "Redefined M4 Macros".)

I agree;  *all* `m4_*' macros need to be documented, either in some
section appropriate to their use, or collectively -- perhaps even
both, with a collective summary pointing to detailed descriptions
elsewhere.

Please don't take this as any denigration of the effort that has
gone into autoconf;  it's an excellent tool, and I wouldn't be
without it.  The foregoing is simply my opinion, but perhaps the
developers do need to occasionally take a step back, and try to
understand the users' perspective of this complex beast.

Keep up the good work.

Regards,
Keith.