[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: listing currently defined macros
From: |
Gary V. Vaughan |
Subject: |
Re: listing currently defined macros |
Date: |
Tue, 19 Feb 2008 14:07:29 +0800 |
Hi Eric,
On 19 Feb 2008, at 02:19, Eric Blake wrote:
According to Gary V. Vaughan on 2/17/2008 2:07 AM:
Hi Gary, and thanks for a review of my ideas, plus some cool ones of
your own.
What a team! Glad you like :-)
| However (breaking my own rule about not introducing additional
macros if
| at all possible), I think list sorting and filtering are both
useful enough
| idioms that we should break them out into new builtins so that our
users
| needn't resort to the hackish things you mention below... which
merely
| highlight deficiencys in the current language implementation. Also,
| m4symbols proper will be faster in the case where the order of
returned
| symbols is not important. So:
|
| -- Builtin (gnu): m4symbols([NAMES...])
| With no arguments, `m4symbols' expands to a unordered, comma-
separated
| list of the names of all currently defined macro. Each macro
name is
| quoted.
In other m4 implementations (I tested Solaris and OpenBSD), dumpdef
output
is also unordered - it is only ordered on GNU. But I would be okay
with a
documented change to dumpdef behavior to be unordered, particularly
since
we could then do:
define(`dumpdef', `builtin(`dumpdef', sort(m4symbols))')
to recover the former behavior.
That's interesting... yes, most definitely.
| -- Builtin (list): sort(NAME, [...])
| Expands to a sorted, comma-separated list of quoted NAME
arguments.
| This macro was added in M4 2.0.
At which point, the user can easily create:
define(`cmp', `ifelse(`$1', `$2', `0',
~ (sort(`$1', `$2')), `($1,$2)', `-1',
~ `1')')
Or, we can define it for them in a directory module of m4 with
supporting
dsos :-)
| -- Builtin (list): uniq(NAME, [...])
| Expands to an unordered, comma-separated list of quoted NAME
| arguments,
| with only the first occurrence of duplicate consecutive
parameters
| listed in the expansion. This macro was added in M4 2.0.
|
| uniq(m4symbols(`ifndef', `ifdef', `define', `define', `ifdef',
| `undef'))
| =>ifdef,define,ifdef
Don't you mean
~ =>ifndef,define,ifdef
No no. There is no ifndef builtin, so m4symbols expands to:
`ifdef',`define',`define',`ifdef'
But (for ease of implementation) uniq only discards consecutive
duplicates,
so the two ifdefs are both kept.
| -- Builtin (list): filter(PATTERN, LIST, [PATSYNTAX])
| Expands to an unordered, comma-separated list of quoted LIST
elements
| that match PATTERN, either according to the current RESYNTAX
(*note
| Changeresyntax::) or PATSYNTAX if passed.
|
| define(`dquote', ``$@'')
| =>
| sort(filter(`*def*', dquote(m4symbols), `GLOB'))
| =>define,defn,dumpdef,ifdef,popdef,pushdef,undefine
Hmm. This would be the first builtin that takes a quoted list of
elements. Maybe it would be worth also making dquote builtin:
- -- Builtin (list): dquote(ELEMENT, ...)
~ Expand to a quoted, comma-separated list of quoted list ELEMENTs.
so that you could use dquote regardless of the current quoting
characters
(in your example, it would only work with `'). Then again, dquote
is easy
to implement efficiently without needing another builtin, unlike
filter
(which can be implemented, but requires a foreach loop).
I agree. Eventually we should try to be kind to users passing around
quoted
lists, and having a quote agnostic dquote is a good plan.
Although, perhaps (as part of the plan to level the playing field
between
C builtins and m4 macros) we should provide some means to write a not-
yet-
expanded-quote character in the definition of a macro, which turns into
whatever is a valid quote at expansion time. I haven't thought about
this
much yet, but maybe a reverse syntaxtable lookup builtin:
-- Builtin (gnu): syntax(SYNTAX-CATEGORY)
Expand to a quoted, comma-separated list of quoted syntax table
entries that have SYNTAX-CATEGORY. SYNTAX-CATEGORY is one of the
letters used to change syntax with the `changesyntax' builtin
(*note Changesyntax::).
Ofcourse the problem with this idea is how we deal with unbalanced quote
characters. Otherwise, I like the introspection it provides.
| I'm sure we can implement several of the m4sugar style list
mangling macros
| eventually, hence I've put these new builtins into a separate list
module.
Sounds like a good idea to me. I'll see if I can get some time to
write
up such a module.
Excellent! :-D
|> So maybe you could argue that we already have
|> globbing if you can just translate the pattern correctly).
|
| I think this proposal has that covered.
I like the idea of using 'GLOB' as another regex syntax, although it
implies some intelligence in the underlying regex builtins (either we
would do glob->regex translation ourselves, or we would have to decide
between re_search vs. fnmatch).
I think the latter will better build on existing proven code, and can
probably be factored somewhat to prevent duplication among builtin
implementations.
Cheers,
Gary
--
())_. Email me: address@hidden
( '/ Read my blog: http://blog.azazil.net
/ )= ...and my book: http://sources.redhat.com/autobook
`(_~)_
PGP.sig
Description: This is a digitally signed message part