m4_dumpdef and m4 1.4.x (was: [PATCH] add m4_stack_foreach and m4_stack_foreach_lifo)

[Eric Blake]

Eric Blake <ebb9 <at> byu.net> writes:

> > Ok.  But no m4_dumpdefs, because it writes on stderr and confuses
> > autom4te.
> 
> Ouch.  So it does (if you aren't using m4.git's master branch).

Phooey.  My rewrite of m4_dumpdef[s] to force output to stderr in spite of m4 
1.4.x's insistence on the builtin writing to the current --debugfile causes a 
problem:

m4_dumpdef([m4_dumpdef])

now outputs the less-than-helpful:

m4_dumpdef:     []

instead of the desired

m4_dumpdef:     <dumpdef>

This is not technically a regression (since before my patch, any use of 
m4_dumpdef under M4 1.4.x flat-out confused autom4te), but it would be nice to 
fix.  One idea I've had is changing autom4te to pass -D_m4_debugfile="file" 
instead of the current --debugfile="file", and change m4sugar to call

m4_ifdef([_m4_debugfile], [m4_debugfile([_m4_debugfile])])

at initialization, so we could write m4_dumpdef as:

m4_debugfile[]m4_builtin([dumpdef], $@)m4_debugfile([_m4_debugfile])

which will force M4 1.4.x to output the dump (including builtins) to stderr 
while still respecting the fact that autom4te needs to collect trace output.

But calling m4_debugfile as part of m4_init is too late (you lose the ability 
for autom4te to trace m4_define calls expanded prior to the m4_init); and 
calling it as part of m4sugar.m4 is too soon (frozen files don't track the 
current debug file, so reloading from a frozen file would behave differently 
than an initial run).  About the only way to pull this off is to teach autom4te 
to include a source file after any frozen files are reloaded, but before the 
first user input file, that executes the appropriate m4_dumpdef, and that seems 
rather tricky.

Another idea would be defining a lookup hash for all the standard builtin names:
m4_define([_m4_dumpdef(m4_define)], [[<define>]])
m4_define([_m4_dumpdef(dnl)], [[<dnl>]])
...

but then how do you keep that table up-to-date when someone does:
m4_copy([mylen], [m4_len])

without making m4_define much more expensive?

I can't even do anything like this:

m4_define([m4_dumpdef],
[m4_case(m4_defn([$1]), m4_defn([m4_define]), [[<define>]],
                        m4_defn([dnl]), [[<dnl>]],...
         [m4_builtin([dumpdef], $@)])])

because the ability to pass builtin tokens through m4_if didn't appear until M4 
1.6.

For m4 1.6, where dumpdef output always goes to stderr instead of to the 
debugfile (well, it will, once I check in a backported patch from the master 
branch), I can make m4_dumpdef useful.  But I'm stumped for any ideas that 
would make m4_dumpdef usable with m4 1.4.x while printing more than an empty 
string for any definition that maps to a builtin, and without crashing 
autom4te, so for now, I've just documented it in the manual.  Fortunately, it 
isn't really a regression, as m4_dumpdef has never really worked with autom4te.

-- 
Eric Blake