Re: head - more frozen file tests

[Gary V. Vaughan]

Hi Eric!

Eric Blake wrote:
> Gary V. Vaughan <gary <at> gnu.org> writes:
>> Yes, in fact we even jump through some hoops to make that possible
>> (see deferred options loop in main.c).
>>
>>>  Or should we claim that all options that affect state
>>> are invalid in combination with -R, since the state should instead be set
>>> by virtue of the reloaded state?  It could certainly make implementation
>>> easier (even your new -r option to set resyntax would qualify as something
>>> incompatible with -R).
>> It would save a couple of dozen lines of code that we already have,
>> but I like the flexibility of being able to, say:
>>
>>   # Freeze a macro base using RE_SYNTAX_EMACS
>>   m4 -F base.m4f base.m4
>>   # Use it with another macro set developed using RE_SYNTAX_EXTENDED
>>   m4 -r extended -R base.m4f macros.m4
> 
> OK, I can see how that might be useful (but it is more complex to get right). 
>  
> And it means my proposed AT_CHECK_M4_FROZEN really needs two sets of args, 
> for 
> true testing of all argument scenarios we want to support: `m4 ARGS1 file1 
> file2' should match `m4 ARGS1 -F file1.f file1; m4 ARGS2 -R file1.f file2'.

ACK.

>> And no need to go in and edit either file 
>>
>> Hmmm... on second thoughts, we need another hoop to accomplish that:
>> each frozen macro would need to record what regexp syntax it assumes.
>> I'll add it to my todo list.
> 
> I'm not sure I follow.  Any `F' directive in the frozen file of one of the 
> three regex builtins just says that the following name maps to the builtin, 
> without regards to which syntax.  Any `T' directive in the frozen file that 
> contains a string that can be rescanned with one of the three regex macros 
> can 
> either explicitly asks for the right regex syntax, by supplying the optional 
> parameter, or uses the current default, even if the current default is 
> different than the one when the text macro was defined.  But I don't see any 
> reason for a macro's definition to remember what the default syntax was at 
> the 
> time it was defined, any more than a macro's definition should remember what 
> the quoting was at the time it was defined.

Actually, this is an idea for quotes I've been incubating for a while,
and it makes more sense in that context...

Let's say I want to use some of the frozen files from m4sugar, along
with a macro library of my own.  The problem is when my macro library
uses standard quotes and m4sugar uses custom quotes:  unless I'm really
careful to change to the correct quotes each time I call a function
from either frozen file, especially if my aforementioned library wants
to call macros from m4sugar.  So we end up with a mess that makes reuse
painful enough to be worth avoiding :-(

On the other hand, if each T directive records what quote characters it
uses when frozen (i.e. we keep track of what quotes all of our
macros are using in the symbol table), and we use a stack to track the
current quotes (an enhancement to syntax tables I want for other reasons
anyway), we can push and pop quote syntax to match each called macro --
enabling unprecedented reuse of m4 macro libraries :-)

(Note, the implementation optimises away the common case of calling a
macro with the same quote syntax as the caller.  Note also, we might
want to play with pushing and popping any part of the syntax table that
changes across function boundaries, and I have some ideas about how to
do that reasonably efficiently under typical use patterns.)

> Anyway, here's my first cut at freeze.at; I'm also checking it in.
> [[...]]

Looks good.  Thanks!

Please let me know if you have any objections to my patch-26.  I'll
check it in over the weekend if not.

Cheers,
        Gary.
-- 
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://blog.azazil.net
GNU Hacker           / )=   http://trac.azazil.net/projects/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

signature.asc
Description: OpenPGP digital signature