On Tue, Sep 14, 2004 at 04:03:49PM +0200, James Mastros wrote:
> 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.
I think you meant something akin to C< /(.) { use PIR; print P0;}/ > and
C< /(.) { use Forth; P0 print}/ > :-) As long as we're special-casing
things and "hand parsing" we might as well use a small subset of Perl)
> 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.
I'm not sure I understand what you mean by "the compliation interface"
here.
> - It means that we have a more complicated grammar engine (slightly).
There's a certain amount of complexity we have to deal with anyway.
As long as we introduce the minimum amount necessary to acheive the
maximum functionality, we're good.
> - It means that we're changing the one bit of perl6 that we just said
> hadn't been changed much.
It's writ in still-soft clay anyway :)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
