multidigit arguments [was: RFC: m4 2.0 --prepend-include option]

[Eric Blake]

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

According to Paul Eggert on 8/23/2006 11:59 AM:
> 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.

I participated in the austin group telecon today, and although the minutes
have not yet been published, I can report on a couple of the aardvarks.

XCU ERN 111 met with some heavy resistance, and remains open for some more
discussion.  The thought from the austin group was that there are more
existing scripts out there that depend on SysV semantics ($10 is the first
parameter concatenated with 0) than there are scripts that would benefit
from GNU semantics ($10 is the tenth parameter), and that it is probably
too late now to change POSIX to allow GNU behavior as a clean extension
because of the existing scripts it would break.  It looks like this may
have to be controlled by POSIXLY_CORRECT indefinitely.

However, sentiment was also expressed that it might be possible to
compromise, by coming up with another syntax that makes it unambiguous,
while being less likely to break existing scripts.  For example, in shell
scripting, ${11} is distinct from $11.  The question was raised whether
making something like the sequence ${ in macro definitions unspecified
would be adequate to resolve the concerns of existing scripts while
allowing GNU to still easily support more than 9 positional parameters.  I
have the action item to report back to the austin group with a proposed
wording along this front.

Some thoughts that I would like feedback on.  First, if we introduce a
grouping character (such as ${11} meaning the eleventh argument), it would
lend itself easily to other extensions such as named parameters, or
shell-like modifications (${1-default} and the like), or any other
situation where we need to unambiguously know how many characters after
the $ are for parameter selection vs. literal text.  But unlike the shell,
we have no way to escape $ or { - right now, m4 treats ${ as two literal
characters.  I think we are still okay, here - if the user wants these two
characters literally, they do the same as they would to get a literal $1,
by using appropriate nested quoting:

define(`foo', `$`'{ $`'1')

Another thing to consider is whether { is the right character to use as
the default for introducing a multi-character parameter.  Since autom4te
is one of m4's biggest clients, and it uses m4 to spit out shell code
(where ${ is liberally expected to be preserved literally right now), I
expect a lot of breakage might occur.  Would $() be any better, since
autoconf currently avoids this shell construct?  Although that still
interferes with Makefile syntax.  $[] would be a non-starter, since
autoconf uses that with changequote.  Maybe $<> is the way to go?  And
there is always the changesyntax macro in m4 2.0 to allow applications to
choose something other than the default.

Also, can we start to get a rough idea of how many existing m4 clients
actually depend on $10 or greater, vs. how many use the sequence $< and
expect it to pass through literally?

> 
> 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.

XCU ERN 119 is another one of these - the sentiment today was that
supporting a range operator in translit is contrary to POSIX 2001, but
that the next revision is an appropriate time to take my suggestion of
declaring - in the middle of the argument as unspecified (making both the
SysV behavior of treating - literally and the GNU behavior of treating it
as a range valid implementations).

> 
> I don't understand (2); it doesn't seem to be documented.  Does it
> really need to depend on POSIXLY_CORRECT.
> 
> For (3) perhaps we can ask POSIX to allow the GNU behavior; then
> we can remove the POSIXLY_CORRECT dependency.

That was XCU ERN 118, again the sentiment was that the next revision of
POSIX will make it legal for an implementation to have define follow GNU
semantics.

> 
> 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.
> 

There are still a couple of other undiscussed ERNs that will impact m4 and
POSIXLY_CORRECT behavior, and I am still debating about submitting an
aardvark regarding whether blind macros are permissible.

- --
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

iD8DBQFE7dpq84KuGfSFAYARAkWPAJwOKofoRTNjLLEdeTuoCs+Tvy/1GQCgtjXe
ShS1QcA0nDxwc0RqXbTJW7U=
=K6fc
-----END PGP SIGNATURE-----