On Wed, Sep 08, 2004 at 09:56:12AM -0700, Larry Wall wrote:
On Wed, Sep 08, 2004 at 07:33:45AM -0600, Patrick R. Michaud wrote:
: We're in the beginning stages of building a basic perl 6 grammar engine : (i.e., probably without p6 closures) that compiles to parrot and handles
: basic optimizations.
I wonder whether, in the absence of closures, we'll have to have some
similar way to embed syntax-tree building code (PIR?) as actions in
the grammar.
We may indeed need this. I think the easiest way would be to
build some sort of "special-purpose" assertions or rules that
fire off some PIR code.
Or, instead of thinking of this as a special-purpose thing, consider rules to be a sepperate language from perl, mostly independent of it, and the /default/ language for assertations/rules being perl, but allow a :<language> attribute to have them be in PIR instead. (Or, presumably, anything else that we can pass off to parrot's compiler interface.) That is, C< /(.) {:PIR print P0;}/ > contains an embedded closure that is PIR code. C< /(.) {print $0;} > contains an closure that is perl6 code (which will fail, hopefully at compile-time, until we have a parrot-callable perl6 compiler), and C< /(.) {:forth P0 print}/ > contains an embedded forth closure.
This means that we don't have to throw all the PIR-using grammars out when we want to be able to use "real" grammars, because PIR-using grammars /are/ real grammars. Ideally, we can even make a :embeddedlang('PIR') to set the default, to enable better re-use from other languages.
Now for the cons: - The compilation interface doesn't have any way to be given a bunch of code that includes code in the target language in the beginning, that will consume that, then hand the rest back to us. - This means that the grammar parser has to figure that out itself. - ...until we extend the compilation interface. - It means that we have a more complicated grammar engine (slightly). - It means that we're changing the one bit of perl6 that we just said hadn't been changed much.
-=- James Mastros