Larry Wall <[EMAIL PROTECTED]> writes:
> Rafael Garcia-Suarez writes:
> : Larry Wall wrote in perl.perl6.language :
> : >
> : > Such a grammar switching routine could operate either over a lexical
> : > scope or over the rest of the file. The only restriction is that
> : > one module not clobber the grammar of a different module.
> : >
> : > Basically, we're trying to make the opposite mistake of the one
> : > we made with source filters. :-)
> :
> : I see that. But should it be possible to import grammar rules,
> : to allow :
> :
> : use Some::Module::That::Modifies::A::Grammar::Rule;
> : # continue to parse the perl program with the modified grammar
> :
> : or even :
> : {
> : use Some::Module::That::Modifies::A::Grammar::Rule;
> : # continue to parse the block with the modified grammar
> : }
>
> Well, it's kind of klunky to do an import every time. More likely
> you'd import a special subroutine once that you can use like this:
>
> Java {
> whatsit.blorf.unnecessary.bletch.extra.something.whatever(1);
> }
>
> Perl 5 is restricted to doing compile-time actions using BEGIN or
> use. In Perl 6 there will be some way of marking a normal
> subroutine as as grammatically active, so that it's called
> immediately, even before its arguments are parsed. Our hypothetical
> Java subroutine above could switch to a Java grammar, parse its
> block, and then restore the Perl grammar at the end.
In a use.perl post not far away I sketched out something like the following:
module foo is Mixin {
sub category($category, &block) {
&block.abstract_syntax_tree.walk_with -> $node {
when AST::Method {
.attrib(category => $category) if .parent =~ █
}
}
}
Actually, my naming choices were rather worse, I originally suggested
'optree', but the optree is really too low level for a lot of things.
# Which leads to thoughts of:
macro Java(&block is rw) {
&block = &block.source.parse_with( Parser::Java )
}
}
(The idea here is that 'macro' would get the block 'earlier' while the
raw source is still lying around, and before perl has started to throw
syntax errors.)
> : And what about switching to a different or modified tokenizer ?
>
> It's not clear that the lexer is a separate entity any more. Lexers
> were originally invented as a way of abstracting out part of the
> grammar so that it could be done in a separate pass, and to simplify
> the grammar for the poor overworked parser. But you can write a
> grammar for an identifier just about as easily as for an if-then-else.
> More easily, if we're basing it on regexes. If we're viewing all
> grammar through the lens of regexes, we're really starting out closer
> to Lexerland anyway, and generalizing toward parsing, a traditionally
> weaker area for Perl. And that's an odd weakness for a text
> processing language.
I am *so* looking forward to Apocalypse 5...
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
