On Tue, Aug 27, 2002 at 01:38:26PM -0700, Sean O'Rourke wrote: > On Tue, 27 Aug 2002, Steve Fink wrote: > > I would like to take a shot at making perl6 front- and backend > > adapters for languages/regex, but so far I have seen all the tests in > > languages/perl6 pass exactly once (and I updated again immediately > > after, and a bunch of them broke again.) So I'm a little nervous about > > digging into it just yet. > > Do you just want to define some calling conventions? If so, we could fix > those in stone (or thick mud) now, and worry about the stability of the > two parts later. Hopefully the degree to which perl6 passes its tests > won't affect the regex engine's behavior too much, and if we choose > something that makes sense and isn't too complicated, perl6 (and regex) > can change quite a bit while maintaining the interface. Especially if > said failures are in the regex tests -- putting regex in will _fix_ those > ;).
That would work, but I really don't want to interfere with anything you're doing by prematurely fixing anything down. IMHO, your current regex code that is highly integrated with perl6 is a far better way of approaching the problem right now. It will produce results faster (eg, in time for 0.0.8), and is the best way to make perl6 and imcc regex-friendly. On the other hand, I still think a separable, language-neutral regex engine is the better long-term plan. Fortunately, our engines are quite similar in spirit, so it seems productive to keep working on them independently; I think there's a good chance we can unify them later. I'm perfectly happy writing an adapter layer for the time being between perl6 calling conventions and languages/regex, and updating it as things change. ========= For those following along at home: regex engines seem to be too much fun for people to resist. I know of at least 5 parsers, 4 compilers, and 5 backend op sets that have been written over the course of the Parrot project: Parsers: - My languages/regex/lib/Regex/Grammar.y (only perl5 re's, crappy) - Jeff's languages/perl6re.bnf - Didn't Sean have another one? - Whatever Simon Cozens is using - Whatever Mark Kvale used Compilers: - My languages/regex - Sean's in languages/perl6 - Mark Kvale's benchmarking implementation - Simon Cozen's current one - Didn't Simon have an earlier (pre-A5) one too? Backend ops: - Brent's original rx ops - The rx ops with Angel's modifications - My abandoned implicitly backtracking re ops - Plain pasm ops - Simon Cozen's tree walkers Many of these fed off of each other. Brent Dax's rx.ops documentation gave both Sean and me the initial start on explicit backtracking code generation, and Mark Kvale drew from both Brent's and mine. Sean and I discuss implementation ideas a little, and I think some more happens on IRC that I don't know about. Currently, Sean's stuff is very well integrated with perl6; my stuff is pretty much ignored; and I envision Simon standing off to the side, rubbing his hands together and cackling "I'll show them all, the fools!". Mark Kvale disappeared soon after posting some very interesting benchmark results. The differences between the surviving (known) three compilers is that Simon's keeps a runtime expression tree and traverses over it, resulting in a somewhat simpler implementation and more flexibility in terms of dynamically swapping in new rules and implementing some of the trickier perl6 constructs. Sean's and my engines both render out straight pasm instructions, though Sean's uses the rx ops and I only use basic pasm ops. My compiler does a fair amount of optimization; Sean's plays well with perl6. Mine is also aiming to support languages other than perl6, which means more work is required in defining the interface between the regex compiler and the language so that it can do the funky new stuff in A5. And I'm not sure why I just wrote all that up.
