--- David Storrs <[EMAIL PROTECTED]> wrote: > On Mon, Jul 21, 2003 at 12:19:11PM -0700, Austin Hastings wrote: > > > Likewise: > > > > my $fh = open "<perl.1.gz"; > > > > $fh =~ /<Grammars::Languages::Runoff::Nroff(input_method > > = Grammars::Languages::Runoff::tbl(input_method > > = Grammars::Language::Runoff::eqn(input_method > > = IO::Gunzip)))>/; > > > Very cool. > > Assuming this ran successfully, what would the match object contain? > Or, more specifically, how would you get the pieces out? Using $1, > $2 > etc would get cumbersome...is there an easier way?
I thought about that briefly when composing my original reply. Obviously, you want the act of invoking the grammar to "do something". That is, when you say: my $fh =~ /<Grammar>/; you want it to DTRT. So what's TRT? IMO, for complex grammars it's going to build a parse tree, complete with associated structures (symbol tables, etc). Thus, the "Match" object will be the head of a really, REALLY big data structure. Technically $0 should probably refer to the entire file (as a String) and to the parse tree (as Object). But an "extra" method for this GrammarParseTree object would have been added -- C<getPreprocessed> or some such -- which returns the entire file after cc -E. So having Grammar::TopLevel call getc() (or whatever) which then (because C<input_method = Grammar::BottomLevel>) accesses its own internal string from Grammar::BottomLevel which presumably has been remapped to the "right" format -- that's what a preprocessor does, no? Obviously, the engine should be smart enough to read far enough ahead to generate correct output, but no smarter. =Austin
