Re: Suggestion to allow macros that don't expand within "string"

On 06/18/2014 03:10 PM, Daniel Goldman wrote:
> For some future m4 version, I'd like to suggest an alternative
> "m4_define2" (or other more clever name) that is the same as m4_define,
> but the newly defined macro does not expand if within a double-quoted
> "string". This would be useful for me, and I think for others too.

Sorry, but the historical m4 language does not have an intrinsic notion
of a double-quoted string - the only quoting it has is what you get via
`' (or via whatever you pass to changequote); and the way the m4
language is designed, the start and end quote work best when they are
distinct from each other.  Adding in support for quoted tokens whose
beginning and end token are the same byte is a MAJOR undertaking that
drastically changes the language; you would no longer be writing m4, but
a new macro language.  It's not to say it's impossible, but you'd
definitely be treading in new territory.

> As a workaround, the input file can (possibly) be modified to produce
> the needed results. It seems the diagnostic macros I use might need to
> be modified to add another argument with double quote delimiters. In
> other words, DIAG_INT(MACRO_1) might need to be changed to something
> like DIAG_INT(MACRO_1, ``MACRO_1''). But this is tedious, and puts the
> effort on the user. And I already tried it. It's not trivial getting it
> to work correctly. Instead of making the user flail around, I think it's
> better to improve m4.

It's open source - you're welcome to try your hand at the improvement.
But it is such a major undertaking that I'm not holding my breath for it
from anyone soon.  I don't think you'd even need a new m4_define2;
rather, just the addition of a new syntactic element for double-quoted
string and the ability to turn on or off whether double-quoted strings
are lexed differently.

If you want to try your hand at it, the first thing I'd suggest is
modifying enum token_type in m4.h to add a new TOKEN_DSTRING, teach
input.c how to parse double-quoted strings, and figure out what new
builtin macro to add to be able to toggle whether double-quoted strings
should be treated specially (and even what their delimiter is) from that
point on in the processing.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJToghuAAoJEKeha0olJ0Nq0MkH/38bqvZCMBjyE6m3N+94/JiA
Lz2xUiUgu/J1nN1IBDicN7udtgkaFxsSrRMW0mKJWkPfZDrvCo0c8cdNEbTCuOLB
dHfB6vJ5UWODVkSK6ht0LY+vVkCqFlJecCbBDwF6V2T0JGRdRe+T/CRsOxcJFpnd
lIT4t/RgfY9f1p03JPBDbD+VwPWjsn+vZltU9YfF4DVDytflb4toWZCDwLOTywc5
TdUxq0bovzaIwahzSdG3ity9X9Bp8iPnNdUoLUorRwsZfARJ00egfmoMO1KR1yXj
V0DNBY8EKrcGIZL67yQX0LlCWiVzQNIWvnLFYkZcxels+tPxwbniQxa18gpvcfE=
=LHiv
-----END PGP SIGNATURE-----