Front page | perl.perl6.language |
Postings from April 2003
Ugh. Sorry for all the missing words and typos and such everyone. My brain was way ahead of my fingers.... Luke > This ties into something I was thinking while pondering the regex > engine. Indeed we have "parse objects" (though we don't quite know > how they behave), and I think we also need "parser objects." And I > think the regex core needs to support them. > > As I see it, Perl 6 will prove the most powerful parsing tool > since... well... never. And Perl 6 has a very nice syntax for > grammars, and patterns in general. > > But, parsing problems have trade-offs for expressiveness, power, and > speed. And a recursive descent is one of the more powerful, but also > quite slow. And, there is no catch-all best algorithm for parsing. > So, instead of forcing a recursive descent on people, they should be > allowed to choose with of several algorithms they want. And it should > be easy to write parser back-ends to the regex syntax. Easier than > walking the parse tree (even though we don't yet know how easy that > would be). And the default would probably stay recursive-descent for > its power. > > So, if one was doing complex parsing, one could C<use Parser::Earley> > (naturally written by me this time around, too :). If one was doing > paring on large grammers with tokenizable input, one could C<use > Parser::LALR>. And then Perl 6's regex engine is still the fastest on > the market, because the programmer can choose which variant is the > fastest for his/her specific application. > > So, how does this relate to the discussion at hand? Well, maybe > parsers are implemented policy-wise. Then you could replace the > default character atom with a Colorific atom. > > my $colorific_parser = new Parser::RecursiveDescent( > atom => Colorific ); > > $colorific_parser.parse(@skysamples, /./); # Matches one Colorific > > The method by which is specified probably has to be more powerful than > that. > > The motivation for this kind of generalization is that pattern > matching applies to a lot more than matching sequences of characters. > C<Parser::LALR> needs tokens, possibly tokenized from > C<Parser::DFA>. Or in the more abstract sense, patterns can be applied > to multimethod matching, as a custom dispatcher. And then classes > need be our atoms. > > I hope this whet somebody's appetite for abstract thinking. Patterns > are just too powerful for text. > > LukeThread Previous | Thread Next