Re: RFC: m4 2.0 --prepend-include option

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[dropping autoconf]

According to Paul Eggert on 8/23/2006 11:59 AM:
> Eric Blake <address@hidden> writes:
> 
>> So by that proposal, a user could then do 'POSIXLY_CORRECT=1 m4
>> -B1024' to get the same behavior with GNU or Solaris m4, regardless
>> of the presence of ./1024, because path searches would be disabled
>> in the GNU version thanks to the implicit -G.
> 
> This doesn't sound right.  POSIXLY_CORRECT is supposed to do just one
> thing: change behavior where GNU applications are incompatible with
> POSIX.  It is not supposed to disable extensions that are compatible
> with POSIX, nor is it supposed to affect compatibility with
> traditional behavior not specified by POSIX.

Agreed.

> 
> Since POSIX does not specify the behavior of m4 -B, we can define m4
> -B to mean whatever we like, independently of whether POSIXLY_CORRECT
> is set.
>> If I make -B a synonym for --prepend-include,
>
> Why -B?  Can't you use a different letter?
>
> Or why not just leave it alone?  It's unlikely people will use this
> option when invoking M4 by hand, so the benefit of a short name for it
> is fairly small.
>

autom4te already uses -B as a synonym for --prepend-include, modeling it
after gcc's -B.  I guess it boils down to whether m4 2.0 should strive for
a command-line compatible interface with other existing m4
implementations, or whether we tell users that to get compatible behavior,
they have to write a wrapper shell script around m4 that loads the correct
m4 module which provides the semantics of the other implementation.  I'm
leaning towards defining -B to always mean --prepend-include, and nuking
- -S and -T support (the other two arbitrary limit tweaking parameters of
Solaris m4) rather than leaving them in as undocumented no-ops.  But I'd
still like to hear Gary's opinion as an official m4 maintainer, before
checking in my proposed patch (or slight modification thereof).

> 
> 
>> I would rather see POSIXLY_CORRECT imply -G, add an option -g
>> (--gnu) to override it (and some BSD versions already have -g to
>> turn on GNU compatibility), and then base all compatibility
>> decisions solely on whether -G is in effect.
> 
> That would be fine, but the behavior of --prepend-include should not
> be affected by POSIX compatibility decisions.  We want POSIXLY_CORRECT
> to affect behavior as little as possible.  So if you go this
> direction, -G should not disable GNU extensions; it should merely act
> like POSIXLY_CORRECT does, and disable _incompatible_ GNU extensions.
> 
> Most GNU applications do not have an option to disable all GNU
> extensions.  Such an option has only a small benefit to the GNU
> project, and nobody uses these options except perhaps for some POSIX
> nerds.  (I'm a POSIX nerd, and I don't use them, so my guess is that
> the size of the audience is zero.  :-)

I see what you mean - if someone really wants their m4 script to be
portable to other implementations, they will only use what POSIX
specifies, rather than relying on non-POSIX extensions (whether they be
from GNU m4, or extensions from another implementation such as Solaris' -B
parameter).  Which is why I'm trying to consolidate no_gnu_extensions and
posixly_correct into a single switch (right now, -G already turns on both
booleans), and minimize what that switch changes, in order to simplify the
effort of testing the effect of the switch on other features.

> 
> I think it would be fine if you removed -G from M4; there's no
> particular reason to pollute the option space to worry about POSIX
> compatibility issues.  Or if you want to keep -G, it would be fine to
> silently ignore it, or to change it to mean "disable incompatible
> extensions" (i.e., behave like POSIXLY_CORRECT) rather than "disable
> all extensions".  But in the long run it'd be simplest to just remove
> it.
> 
> While we're on the subject.....
> 
> Looking at the code, POSIXLY_CORRECT now affects the following
> behaviors of CVS M4:
> 
>    1.  Multidigit arguments of $, e.g., $10.
>    2.  Value arg signatures, whatever they are.
>    3.  Whether 'define' implies 'undefine' or 'popdef'.
>    4.  Whether 'undivert' accepts a non-numeric argument.
>    5.  Whether options can follow operands in the command line.
> 
> In XCU ERN 111 you asked for changes to POSIX so that (1) would be
> allowed as a compatible extension; if this is accepted, we can change
> M4 so that it supports (1) even if POSIXLY_CORRECT is defined.

Right now, the only way to affect (1) is via the initial environment;
there is no way for a module to override the parser.  But unconditionally
supporting it was my goal in writing the aardvark.

> 
> In XCU ERNs 99 and 101 you asked for similar changes for (4), and they
> have been accepted by the Open Group.  In situations like these I
> think it's fine to drop the POSIXLY_CORRECT check; that is, the code
> can do (4) without worrying about POSIXLY_CORRECT.  It's OK to
> anticipate the next version of POSIX in relatively-minor situations
> like these.

(3) and (4) could also be solved by writing a module to redefine those
macros with posix-compliant implementations, rather than relying on the
global state from the command line.

> 
> I don't understand (2); it doesn't seem to be documented.  Does it
> really need to depend on POSIXLY_CORRECT.

I wasn't either, and after some sleuthing, found this:
http://lists.gnu.org/archive/html/m4-patches/2003-06/msg00002.html

It looks like an incomplete patch (intentionally tabled until post 2.0) to
allow named parameters.  Perhaps a better thing to do here would be use a
syntax like:
define(`foo{bar, baz}', `arg2: ${baz}, arg1: $1')
foo(a, b)
=> arg2: b, arg1: a

ie. invent a new syntax type for named argument delimiters (here, `{' and
`}').  Then we are completely compatible with POSIX, because { is not part
of a valid macro name, and ${ does not have required semantics.  We could
even hook it into the changesyntax builtin, so that autoconf can continue
to use macro names of [foo(bar)] without confusing it with named
parameters, as in Gary's original writeup.  But I also agree with Akim's
retort that such a feature must be post 2.0, and ensure it doesn't break
existing m4 clients.

> 
> For (3) perhaps we can ask POSIX to allow the GNU behavior; then
> we can remove the POSIXLY_CORRECT dependency.

Actually, for (3), I'm not even sure POSIX has an opinion one way or the
other - it is only the NEWS file of GNU m4 that claims that POSIX required
the undefine() behavior, since that was the implementation choice made by
other implementations.

> 
> For (5) we can perhaps do the same as (3), but this is a bigger deal
> since it affects lots of programs, and perhaps I should attempt that
> (if you want to pursue it) since I know better where the bodies are
> buried.

I thought (5) has already been attempted; at least discussions have been
raised about the issue on the Austin mailing list.  And I am not as
worried about it, because it is the gnulib getopt implementation that
would be affected and not the m4 code base proper.

Other places where I know GNU is currently incompatible with POSIX, but
where POSIXLY_CORRECT does not (yet) have an effect:
 (6) GNU accepts character ranges in `translit', although I intend to file
an aardvark to allow this extension
 (7) GNU treats many builtins as blind (ie. `eval' without arguments
expands to `eval', not `0'), but I don't know if an aardvark is worth it,
as it affects quite a few of the builtins
 (8) GNU treats `maketemp' more like mkstemp(3); I have already filed an
aardvark
 (9) GNU uses traditional m4 operator precedence in `eval' instead of C
precedence; here I plan to fix GNU

and the things currently affected by no_gnu_extensions instead of
posixly_correct:
 (10) whether file inclusion searches a path; seems like a clean extension
of POSIX to me, and should not be conditional
 (11) whether macro tracing survives the macro being undefined; seems like
a clean extension to me, and should not be conditional
 (12) whether the 'traditional' or 'gnu' module is loaded at startup
 (13) whether `m4wrap' takes multiple arguments

Of those, 6, 7, 8, 9, 12, and 13, seem like they can all be addressed by a
module.  In other words, a POSIX nerd could theoretically implement a
POSIX m4 by a simple wrapper script and a (not yet written) posix module:
#!/bin/sh
export POSIXLY_CORRECT=1
exec /path/to/gnu/m4 -m posix "$@"

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE7MoQ84KuGfSFAYARAs+aAJ4m8E5AlCKBPC/G6MHSwJXqJ/PiUgCfdxw7
zC4ad9rZN7Pjam60XPekP7A=
=BYD4
-----END PGP SIGNATURE-----