Re: O(n) patches and side effects

[Ralf Wildenhues]

Hi Eric,

* Eric Blake wrote on Fri, Aug 22, 2008 at 06:23:38AM CEST:
> 
> Meanwhile, I discovered a slight flaw in m4_init that I'm not 
> sure how to fix yet - if you freeze m4sugar.m4f with m4 1.6, but then reload 
> it 
> with 1.4.x, then m4_init sees the __m4_version__ from the frozen file and 
> proceeds to use the quadratic methods, rather than realizing that foreach.m4 
> is 
> needed.  On the other hand, why would people build with newer m4 then 
> downgrade 
> to an older m4?  So I'm not even sure whether this scenario needs to work.

I do this kind of stuff, for testing.  Other people might decide to back
down, when an early 1.6 stable release turns out to have that fatally
ugly flaw that makes their software stop working.  So, it's not exactly
common, and not a show-stopper if it doesn't work, but making going back
easy is nice.  If the scenario doesn't work at all, a note in m4-1.6/NEWS
would be nice.

> From: Eric Blake <address@hidden>
> Date: Thu, 21 Aug 2008 22:17:33 -0600
> Subject: [PATCH] Avoid extra side effects in m4sugar list expansion.
> 
> * lib/m4sugar/m4sugar.m4 (m4_mapall_sep, m4_list_cmp): Wrap
> around...
> (_m4_mapall_sep, _m4_list_cmp_raw): ...new helpers, to avoid
> duplicate side effects.
> (m4_version_compare): Adjust caller.
> * lib/m4sugar/foreach.m4 (m4_list_cmp): Rename...
> (_m4_list_cmp_raw): ...to match m4sugar.

Should foreach.m4 and m4sugar.m4 have comments to the end of
"please keep macro names and semantics aligned with the other file"?
Do you think we may need to put some measure in place to enforce this?

> * doc/autoconf.texi (Looping constructs): Document the behavior of
> side effects.
> * tests/m4sugar.at (M4 loops, m4@&address@hidden, m4@&address@hidden):
> Ensure only one side effect.
> (recursion): Fix test typo.
> Reported by Ralf Wildenhues.
> 
> Signed-off-by: Eric Blake <address@hidden>

Eric, you are an incredible m4 wizard.

Thanks!
Ralf