m4_wrap behavior

[Eric Blake]

The m4sugar documentation assumes that m4_wrap behaves in a
LIFO manner, since that is the behavior of GNU m4 1.4.x's m4wrap.
For example, the docs give this example of how not to use m4_wrap,
because the two wrapped outputs get concatenated and rescanned:

m4_define([foo], [Foo])
m4_define([bar], [Bar])
m4_define([foobar], [FOOBAR])
m4_wrap([bar])
m4_wrap([foo])
@result{}FOOBAR

But POSIX requires m4wrap to behave in a FIFO manner, and with
POSIX, the above example would output barfoo rather than FOOBAR.
I plan to fix the bug in m4 2.0.  The question now is whether m4 2.0
should conditionalize LIFO vs. FIFO based on POSIXLY_CORRECT
(because existing uses of GNU m4 depend on LIFO), or whether this
corner case of m4sugar is not in heavy use, and the fix can be made
across the board.  Then, in m4sugar, we should just document
either that 1) m4_wrap has indeterminate ordering, or 2) m4_wrap
will always be LIFO or FIFO, regardless of the underlying m4wrap
behavior.

As an idea of how to force m4_wrap ordering, this shows how
to give m4 1.4.4 FIFO ordering:

changequote([,])dnl
define([m4wrap_],[0])define([_m4wrap], defn([m4wrap]))dnl
define([m4wrap], [ifdef([m4wrap]m4wrap_,
[define([m4wrap]m4wrap_, defn([m4wrap]m4wrap_)[$1])],
[_m4wrap([define([m4wrap_], incr(m4wrap_))m4wrap]m4wrap_)dnl
define([m4wrap]m4wrap_, [$1])])])dnl

-- 
Eric Blake