On Jun-27, Jeff 'japhy' Pinyan wrote: > On Jun 27, Steve Fink said: > > >On Jun-26, Jeff 'japhy' Pinyan wrote: > >> I am currently completing work on an extensible regex-specific parsing > >> module, Regexp::Parser. It should appear on CPAN by early July (hopefully > >> under my *new* CPAN ID "JAPHY"). > >> > >> Once it is completed, I will be starting work on writing a subclass that > >> matches Perl 6 regexes, Regexp::Perl6 (or Perl6::Regexp, or > >> Perl6::Regexp::Parser). I think this might be of some use to the Perl 6 > >> dev crew, but I'm not sure how. > > > >Sounds interesting, but I'm a bit confused about what it is. Clearly, > >it parses regexes, but what is the output? A parse tree? Tables and/or > >code that implement a matching engine for that regex? PIR? A training > >regimen that can be used to condition a monkey to push a "yes" or "no" > >button whenever you give it a banana with an input string inscribed on > >it? > > It creates a tree structure, not identical but similar to the array of > nodes Perl uses internally.
Ah, good. Then I am interested. When I manage to find some time for hacking again, I'll graft it onto languages/regex as a replacement for the ridiculous parser I have there now. languages/regex is meant to be a language-independent regex engine, and has a silly stub parser to get basic stuff into it for testing. languages/perl6 uses the engine too, but provides its own parser. But nobody's done anything with that parser since Sean O'Rourke stopped working on it (admittedly, he implemented a surprisingly large portion of the syntax), and it'd be great to be working with something that's maintained. (But mostly I like the idea of using a language-independent front-end with a language-independent backend.) I should just look at the code, but I'm wondering what you do with language-specific constructs. Embedded code, for example. How do you find the end of it? And will you be supporting things like Perl6's / $x := (a*b) / where '$x' is a language-dependent variable name syntax?
