m4-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ralf Wildenhues
Subject: Re: M4 syntax $11 vs. ${11}
Date: Thu, 18 Jan 2007 18:35:12 +0100
User-agent: Mutt/1.5.13 (2007-01-09)

[ Can we limit this to, say, the m4-discuss and autoconf lists? ]

Hi Eric,

* 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)])
> 
> that lets autoconf 2.62 warn the user about the portability pitfall, even
> if they are still using M4 1.4.8?  Or even one step fancier:
> 
> define([m4_define], [regexp([$2], [\$][\{],
>   [m4_warning([syntax: raw [$]{ in [$1] will change semantics])])builtin(
> [define], [$1], patsubst([[$2]], [\$\{], [[$]{]))])
> 
> Although the latter may lead to the occasional overquoted $ in output, at
> least the warning points the user in the correct location to fix it.

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.

> 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.
Judging from the size of the diffs alone, this looks all very very scary
and bad.  User macros are going to have a similar amount of code needing
adjusting.  This necessity will be difficult to communicate.

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

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.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]