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

[Eric Blake]

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

According to Ralf Wildenhues on 1/18/2007 10:35 AM:
[ Can we limit this to, say, the m4-discuss and autoconf lists? ]

Sure.

> 
> Hi Eric,

Hi Ralf, and thanks for the feedback,

> 
> * Eric Blake wrote on Thu, Jan 18, 2007 at 03:50:09PM CET:
> [...]
>> So would it be worth trying to change the m4sugar definition of m4_define
>> to something like the following:
>>
>> define([m4_define], [regexp([$2], [\$][\{],
>>   [m4_warning([syntax: raw [$]{ in [$1] will change semantics])])builtin(
>> [define], address@hidden)])
>>
> 
> I'm guessing the overquoted output will break some usage case you
> just haven't encountered yet.  Anyway, not all the world uses `m4_define',
> more often than not third-party macros use `define' and furthermore get
> scanned before the m4sh initialization, so it all won't help much if
> your warning has both many false positives and many false negatives.

OK, so it sounds like making m4sugar smarter with regards to m4_define is
not the way to go.

> 
>> Anyways, here are the patches in their current state:
> 
> Please resubmit without any white-space only changes (e.g., diff -w).
> It makes evaluating the amount of changes more difficult than necessary.

Coming in a later email; the machine I'm typing this mail on is not where
I generated the patch.

> 
>> +When M4 encounters @samp{$} within a macro definition, followed
>> +immediately by a character it recognizes, it will perform M4 parameter
>> +expansion.  This happens regardless of how many layers of quotes the
>> +parameter expansion is nested within, or even if it occurs in text that
>> +will be rescanned as a comment.
> 
> At a first glance, this sounds like a bad and ugly idea to me.
> Can we do better so that ${ is only mucked when $1 would be expanded
> when in the same place?

That's the point - according to M4 rules, if $1 is encountered in a user
macro definition, it WILL be expanded, regardless of context of the rest
of the user's definition.  So in M4 2.0, if ${ is encountered, an
expansion will be attempted.

> 
> Here's a more radical idea: can M4 have a macro to turn this ${11}
> feature off and have ${ expand to ${ always?  Let's expand that macro as
> first thing in autoconf.

Yes.  CVS head of M4 already has changesyntax.  Based on your idea, I have
been working on implementing '{' and '}' syntax categories, similar to the
existing '$' syntax category.  They will default to { and }, at which
point ${1} is treated like $1.  But by calling changesyntax([O+{}]), you
have reassigned { and } to the OTHER (ie. plain char) category, leaving
nothing in the '{' and '}' categories, so ${1} would then output a literal
sequence without parameter expansion.  I'm also considering adding a
command-line parameter --changesyntax, that can do these syntax changes up
front; the problem is that if autoconf is built against m4 1.4.9, then the
user upgrades to m4 2.0, autom4te won't know to use the --changesyntax
option; so you still need to call changesyntax in m4sugar (when m4sugar
detects that changesyntax is defined).

And, as you pointed out, any user .m4 that gets expanded prior to
m4sugar.m4 will not benefit from m4sugar's use of changesyntax.  Maybe it
is time to investigate making autom4te smarter to warn about user's uses
of non-m4sugar macros.

As for m4 1.4.9, I think I will add a --warn-syntax option that turns on
warnings for raw ${, but that autom4te should not need to worry about that
option since it would instead be disabling the ${ semantics via changesyntax.

- --
Don't work too hard, make some time for fun as well!

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

iD8DBQFFsNSb84KuGfSFAYARAr0CAKC/MhDmHRzipJrQUF2z5C5hnLUmWACgpnST
51ROSPonIX39Ba+sxXn0x40=
=BHBO
-----END PGP SIGNATURE-----