[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: m4_map

From: Ralf Wildenhues
Subject: Re: m4_map
Date: Thu, 14 Aug 2008 20:43:55 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

* 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]