[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
yet?
Cheers,
Ralf