Re: M4 syntax $11 vs. ${11}

[Gary V. Vaughan]

Hi Eric,

Wow, I can't believe how much you've done in the last few months! :)   
It's
gonna take me a week or two to get back up to speed on everything...

On 28 Feb 2007, at 20:18, Eric Blake wrote:
> Eric Blake <ebb9 <at> byu.net> writes:
> > With 1.9b, I would like to implement the resolution of XCU ERN  
> > 111.  That
> > is, I plan on adding support for ${11}, so that the GNU extension  
> > of more
> > than 9 parameters is still alive (and in fact, I hope to borrow  
> > from shell
> > syntax for other extensions such as ${1-default}).  I also plan on  
> > making
> > $11 obey POSIX semantics if POSIXLY_CORRECT, else obey 1.4.x  
> > semantics but
> > issue a warning that obsolete syntax was encountered.  Then, after a
> > deprecation period, M4 2.1 could remove the POSIXLY_CORRECT check and
> > always treat $11 the way POSIX requires.
>
> Here (finally) is a patch for head, that both implements ${1}, as  
> well as
> forward ports --warn-macro-sequence from the branch.  The features are
> intertwined enough that I didn't see any good reason to separate  
> this into
> multiple patches (other than the earlier patches I already  
> committed today).
>
> However, I would like a review; so it is not applied yet.

Okay, give me a few days (it's Octavia's birthday in an hour, and  
mine the day
after so I won't be online too much until Sunday (-:).

> In particular, in
> macro.c, this patch does not do a deprecation period for $10, as I  
> originally
> thought above, but flat out went with POSIX syntax.  I did this on the
> principle that relatively few uses of $10 in the wild have been  
> discovered, and
> that --warn-macro-sequence can be used to detect even those uses.   
> Bonus points
> if you can spot the corner case logic problem that I am already  
> aware of in
> macro.c.

One thing that worries me about where M4 2.0 is headed is that the  
default
build seems to me like it will be too different from 1.4.x and suffer  
from
a lot of the problems and bad feeling that surrounded the transition  
from
Autoconf 2.13 to 2.5x :-(  We can avoid this if we take care... why  
shouldn't
people who are stuck in 2.13 land be able to upgrade to M4 2.0  
without pain?
Maybe some of them will find all the cool new functionality we  
already have
in 2.0 and start using it then before giving up in disgust and  
downgrading
to 1.4.x when a bunch of their configure.ins stop building...

> The patch looks big, but part of it is moving implementation of  
> regex functions
> out of modules/gnu.c into m4/resyntax.c for better code sharing;  
> part of it is
> test code; and a lot of it is documentation.
>
> Still to be written:
>
> 1) I want to implement a new builtin m4macroseq([regex], 
> [resyntax]), which
> behaves like the command-line --warn-macro-sequence (and that also  
> means adding
> a command line --m4macroseq for symmetry).  With no arguments, it  
> enables the
> default warning sequence, with one empty argument, it disables  
> warnings, and
> since it uses regular expressions, it takes an optional resyntax  
> argument to
> override the current changeresyntax.

I want to think about this some more before I comment.

> 2) I have promised to implement changeextarg(start,[stop]), which  
> allows multi-
> character extended arguments, so that autoconf can reserve ${1} for  
> shell
> output and ${{1}} for the day that autoconf 3.0 depends on m4 2.0.   
> I will
> model it on changequote, including how it interacts with single- 
> character quote
> syntax in changesyntax, except that an argument always must be  
> supplied (to go
> with the policy that macros not beginning with "__" or "m4" must be  
> blind, to
> avoid risk of inadvertant expansion).

I'm loathe to add the changeextarg builtin, when we should be able to
incorporate the functionality into changesyntax.  I haven't thought too
hard about what arguments changesyntax should take to provide  
changeextarg
(and changecom & changequote) functionality, but I (hope I still) have a
half baked patch to push the multicharacter syntax implementation  
into the
big m4 syntax table, which in turn removes a lot of special case code  
and
opens up some new possibilities for other multicharacter syntaxes at the
cost of slowing the parser down some.  I'll either dust it off or  
rewrite
it and post for review when I've shepherded my libtool patch queue  
backlog
into CVS.

> 3) I would like to implement ideas from sh, such as ${1-default}  
> expanding to
> the first argument if supplied, or `default' if omitted.

I do like this idea a lot.  But I'd be sad to see it pollute 100% 1.4.x
backward compatibility :-(

I also have some parser extension patches that implemented named
arguments with define:

  define(`foo(bar, baz)', `
    ${bar}, ${baz}!
  ')
  foo(`hello', `world')
  =>hello, world!

And argument defaulting:

  define(`foo(bar, baz=`cruel world')', `
    ${bar}, ${baz}!
  ')
  foo(`Goodbye')
  =>Goodbye, cruel world!

At the time, I think Akim wanted a more perl-like syntax, where I had
followed a more lisp-like path.  Since then M5 was pointed out to me,
so I guess this work can support M5 syntax and be the first steps to
implementing the M5 `language'.

> I think that 2) is the only thing that should be completed before I  
> feel
> comfortable baselining m4-1.9b for wider test exposure on  
> alpha.gnu.org.

I'm more than happy to see a 1.9b alpha release as soon as you feel  
ready,
but a showstopper for 2.0 proper is that on a crummy machine that worked
well with 1.4.x, I think 2.0 must have a default preloaded module build,
that is 100% backwards compatible.  Any extensions can either be runtime
loaded on a decent machine, or at worst have additional code  
configured in
at build time on a static only architecture.

My dream is still to modularise the core enough that m4-2.0 will support
different 'languages' (we need a better name for this -- I mean GNU M4
being a 1.4.x compatible, M42 being the new stuff we're putting in that
will break 1.4.x compatibility, M5 etc).

Cheers,
        Gary
--
  ())_.              Email me: address@hidden
  ( '/           Read my blog: http://blog.azazil.net
  / )=         ...and my book: http://sources.redhat.com/autobook
`(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912

PGP.sig
Description: This is a digitally signed message part