m4-discuss
[Top][All Lists]
Advanced

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

listing currently defined macros


From: Eric Blake
Subject: listing currently defined macros
Date: Sat, 16 Feb 2008 13:12:31 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666

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

I have often found myself wanting a subset of the currently defined macros
that matches a regular expression or glob.  But there's no easy way to get
at it, even with the new m4symbols macro on the head, because you have to
know the names of the subset in advance (the manual documents a way to
double-quote the output of m4symbols, then pass that through a foreach
loop to filter it, but it is not very efficient; and while it can do
regex, it can't do glob matching since m4 currently has no globbing
builtins[1]).  What do others think of the following proposal for
redefining the semantics of m4symbols?  Note that since there has been no
release with this macro, we can still tweak the semantics before M4 2.0.

Note that other builtins which take a list of macros will not change
semantics - they still take literal lists, for several reasons.  One, some
of them are specified by POSIX (think dumpdef, traceon, popdef) to take
literal lists, with no room for extensions.  Two, these macros have been
in previous M4 releases, so unlike m4symbols, we can't gratuitously break
backwards compatibility.  And three - simply use m4symbols' proposed
powers to generate a literal list to feed the other macros (similar to how
eval can take arbitrary expressions and turn them into decimal numbers to
feed to other macros like divert that only parse decimal).

m4symbols
m4symbols([`list'], name...)
m4symbols(`glob', pattern...)
m4symbols(`match', [resyntax], pattern...)

With no arguments, list all symbols.

If the first argument is `glob', all remaining arguments are treated as
globs, and all symbols matching each glob are listed (hmm - should symbols
matching multiple globs be listed multiple times?  Should the list be
fully sorted[2], or just sorted for each glob, or unsorted?)

If the first argument is `match' (or maybe also `regexp', except that
regexp is a builtin by default while match is not), the remaining patterns
are regular expressions rather than globs (same questions as for glob).
Additionally, if the second argument is not blank, and matches a resyntax
flavor (such as basic or extended; as in changeresyntax), the patterns
have that syntax (a blank is ignored, necessary if you want to use the
name of a resyntax flavor as the pattern but without changing the resyntax
flavor; otherwise, if the second argument is not a resyntax flavor, it is
silently treated as the first regex pattern using the current default flavor).

If the first argument is `list' (necessary if you want to list the macro
`glob' rather than turning on glob matching), or if the first argument
does not match any reserved key, then all arguments are taken as literal
macro names to list.

[1] (I guess it would be nice to add a globbing builtin as well.  On the
other hand, I seem to recall that globs are a subset of regex - ie. you
can convert any valid glob into a valid regex, although the converse is
not always possible.  So maybe you could argue that we already have
globbing if you can just translate the pattern correctly).

[2] The current implementation of m4symbols fully sorts the output,
matching the way that dumpdef operates.  This can be exploited to perform
sorting of arbitrary lists - for each element in the list, pushdef an
empty macro with a common prefix and the element as a suffix, then pipe
the list through m4symbols for sorting, and post-process the list to
popdef the temporary symbol and remove the prefix.  Not the fastest or
best use of memory in doing the sorting, but since we don't have any other
builtin that sorts or even does lexicographic comparisons, it is rather
interesting to consider.

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

iD8DBQFHt0Ou84KuGfSFAYARAtT9AKCxOJmWIoS/DgK3bH9Om0osz1a7xgCgtPTO
SbPn9Tz4IlQIuLoEUCvP45I=
=ea1H
-----END PGP SIGNATURE-----




reply via email to

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