* 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], [[], [[1]])" now invokes only "func([1])", 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], [-], [[[1]], [], [[]]])" results in "[1]-[]", > rather than "[1]--[]". 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 yet? Cheers, Ralf
