[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Thu, 14 Aug 2008 20:43:55 +0200
* Eric Blake wrote on Thu, Aug 14, 2008 at 03:11:44PM CEST:
> So, to solve things, I'm thinking of the following change:
> m4_map, m4_map_sep no longer invoke func on an empty argument sublist.
> This means "m4_map([func], [])" goes back to being a no-op, while
> "m4_map([func], [, [])" now invokes only "func()", instead of two
> invocations. Additionally, m4_map_sep behaves like m4_join, where the
> separator is omitted if the func call is omitted, so that
> "m4_map_sep([m4_dquote], [-], [[], , []])" results in "-",
> rather than "--". For all cases bison is worried about, this makes
> m4_map go back to its pre-2.62 behavior.
> Meanwhile, I will add two new functions m4_mapall and m4_mapall_sep,
> similar to the paradigm of m4_joinall, where the empty sublist implies an
> invocation of func with zero arguments, so that the 2.62 semantics of
> "m4_map_sep([func], [sep], [list])" are now available as
> "m4_mapall_sep([func], [[sep]], [list])".
As far as I have understood the problem space (which is quite a bit from
fully, mind you), your proposal makes sense to me, if the bison
developers don't have issues with it. I understand correctly that
except for Autoconf and Bison, practically nobody uses these macros