Re: Comments on changesyntax et al.

[Daniel Richard G.]

Hi Eric!

Hope this doesn't intrude too much on your vacation :-)  (Take your time 
replying, of course...)

On Sat, 2007 Feb 10 23:22:27 +0000, Eric Blake wrote:
>
> > instead of the more LaTeX-like
> > 
> >     \macro{arg one}{arg two}{arg three}
> > 
> > which is what I want, not least because it all but does away with the need 
> > to quote the arguments.
> 
> Nice idea, but how best to encode that into what changesyntax can do?

The problem is, changesyntax() can't be used to specify multi-character 
syntax elements like this. You'd need something like a changeargsep() 
builtin.

It's basically the same situation as e.g. the "begin comment" syntax 
category vs. changecom()... ("The default is the single character `#'. For 
multiple-character comment delimiters, use changecom").

> >     Open paren  => "(["
> >     Close paren => ")]"
> > 
> > ...m4 won't recognize (let alone enforce) proper nesting; "foo(bar]" would 
> > be a valid macro call. I don't see how a set-of-characters match is 
> > well-suited for defining these sorts of syntax categories.
> 
> Any suggestions on improving this as well?

The best I can think of would be to add a changeparens() (for lack of a 
better name) builtin.

More generally... my impression is that changesyntax() is great for those 
syntax categories that are naturally character classes (word chars vs. 
whitespace chars and so on), but for "fixed" syntactical elements like 
parens, the argument separator, etc. you really want a dedicated 
changexxxxxx() builtin.

To go a bit further, for discussion purposes... I'd question the whole idea 
of allowing changesyntax() to modify these "fixed" syntactical elements at 
all. That is, I'd add the changexxxxxx() calls, and remove these categories 
from changesyntax()'s control altogether.

I don't know the whole range of "exotic" m4 usages that you want to 
support, but is there any case where you would want, say, the macro 
argument separator (the "," category) to be any one of N characters, where 
N > 1?

It strikes me as a feature that won't be very helpful in real-world usage, 
but that will have to be catered to in all future versions of m4, just 
because you can never assume that *no one* is using it. 
Backward-compatibility and all.

> > On a different note, may I make a feature suggestion/request? I see that 
> > two of the syntax categories address "extended argument references." These, 
> > from what I can tell, work the same way as standard argument references, 
> > except for the extra bit of syntax protection---you can say e.g. 
> > "1111${2}1111" safely.
> 
> Work in progress.  Very much in progress.  The goal is to obey POSIX
> by treating $10 as the first argument concatenated with 0 (rather than
> the 1.4.x behavior of treating it as the tenth argument),

Heh, not unlike Make variable references...

> then to use the POSIX out that ${ is an implementation-defined sequence 
> to treat ${1} as the first argument, just as it is in /bin/sh.  But since 
> this syntax makes shell output awkward, Paul Eggert convinced me to add 
> changeextarg(<start>,<end>), allowing a multiple-character sequence as 
> the delimiters of extended arguments, if desired. Therefore, autoconf 3.0 
> will likely choose ${{1}} as the m4 first argument, leaving ${1} as 
> literal shell output.  But for now, all I've done is implement 
> cingle-character delimiters that aren't even parsed, other than a syntax 
> category is reserved for them.

Just an observation, but would "$(1)" be a reasonable way to reference 
macro args that doesn't conflict with shell syntax? If you add 
changeextarg(), you're already opening the door to using something other 
than the POSIX-defined "${" escape.

> Help would be welcome.  If you plan on making large patches,
> you will need to assign copyright to the FSF.

Now that you mention it... is it (or will it be) possible to write a 
loadable module that adds a new regex flavor? I've been messing around with 
PCRE lately, and being able to use Perl regexes in m4 would be yummy.

(Copyright assignment isn't a problem, btw; I'm aware of the policy.)

> > But that wasn't obvious to me at first, and for a moment I was thinking m4 
> > had gained support for named arguments. Which would have been a really, 
> > really nice feature to have. Something where you could do e.g.
> > 
> >     => define(`foo', `The ${noun} is ${verb}.')
> >     => foo(noun = `fox', verb = `running')
> >     The fox is running.
> 
> You're not the first to have this idea.  But with extended arguments,
> we may have a cleaner syntax.  The only problem I see right now
> is that if I release M4 1.4.9 as is, you would have to wait until
> M4 2.1 for this feature, since Paul convinced me that for purposes
> of a transition period, only ${<digit> should be recognized as
> the start of an extended argument.  On the other hand, that was
> before we came up with the idea for multi-character extended
> argument delimiters, so maybe I should just reserve ALL ${
> sequences in the default warning of M4 1.4.9's --warn-macro-sequence.

So you're saying, the problem is current m4 users who are using ${1}, 
${foo}, etc. in macro bodies, with the intent of having those be shell/etc. 
variable references and not m4 macro arg references?

Also, do you already have a particular syntax in mind for calls to 
named-argument macros? (I'm curious!)

> Like I said, it will be a couple of weeks before I have any more M4
> hacking time, but I appreciate your feedback on the work in progress.

Thanks for hearing me out :)


--Daniel


-- 
NAME   = Daniel Richard G.       ##  Remember, skunks       _\|/_  meef?
EMAIL1 = address@hidden        ##  don't smell bad---    (/o|o\) /
EMAIL2 = address@hidden      ##  it's the people who   < (^),>
WWW    = http://www.******.org/  ##  annoy them that do!    /   \
--
(****** = site not yet online)