[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: the need for qindir
Re: the need for qindir
Fri, 25 Apr 2008 06:55:02 -0600
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/20080213 Thunderbird/126.96.36.199 Mnenhy/0.7.5.666
-----BEGIN PGP SIGNED MESSAGE-----
According to Akim Demaille on 4/25/2008 4:11 AM:
|>>> "EB" == Eric Blake <address@hidden> writes:
| >> Something like a new primitive "eval and return quoted" would fill
| >> the gap.
| > Yes, m4 has a TODO item about adding the qindir builtin (and which
| > I will probably do for m4 1.6).
I've checked in a first draft on the argv_ref branch of m4.git:
It merely expands its argument macro, then surrounds the result with the
current quotes prior to rescanning anything (thus the rescan always sees
the result as a quoted string). It currently aborts on
~ qindir(`include', foo)
but works on most other builtins. One of the trickier points was getting
qindir(`qindir', `changequote', [, ]) to result in [] (ie. add two
layers of _current_ quotes around the empty string output of changequote,
resulting in the output of  after the outer quotes are stripped).
Nested unbalanced quotes are treated the same way on rescan as any other
macro (ie. there is still no way to generically treat an arbitrary block
of text as one unit regardless of whether it contains unbalanced close
define(a,A)qindir(`substr',`a''`a',0) => aA' (not a'a)
With text macros, something interesting happens:
define(`foo', `divnum $#') =>
foo => 0 0
defn(`foo') => `divnum $#'
qindir(`foo') => `divnum 0'
That is, nested macros are not expanded (similar to defn), but parameter
replacement occurs (similar to direct invocation). I'm not sure if this
is this the most useful behavior, although it can probably be exploited
| Why forcing the requirement that the argument is a macro name instead
| of a full m4-expression to evaluate? The user must define a macro
| first. A bit like forbidding anonymous lambda-expressions in a
| function language.
Interesting thought, but doesn't m4_expand meet this role (modulo the
choice of internal quote string)? After all, the goal of m4_expand is to
do full m4 expansion of whatever arbitrary expression was handed in as its
argument, and return the result inside quotes. In other words, I'm not
sure you need a new builtin to achieve this goal.
On the other hand, my implementation of qindir provides something as a new
builtin that cannot be accomplished with existing semantics, namely the
ability to suppress expansion of the output of builtin macros that
generate unquoted text.
Don't work too hard, make some time for fun as well!
Eric Blake address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Re: 2.62 AT_SETUP limitations, Akim Demaille, 2008/04/24
Re: 2.62 AT_SETUP limitations, Joel E. Denny, 2008/04/24