On Tue, Sep 14, 2004 at 08:13:13PM +0200, James Mastros wrote:
> Jonathan Scott Duff wrote:
> >On Tue, Sep 14, 2004 at 04:03:49PM +0200, James Mastros wrote:
> >>Or, instead of thinking of this as a special-purpose thing
> >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)
> You're still thinking in terms of this being a temporary hack.
Actually I was thinking in terms of this being a permanent hack.
> We've
> found ourself in a position where perl6 grammars don't have all the
> functionality needed to write the metagrammar... in particular, they
> don't have the ability to specify embedded code in PIR, only in perl6.
>
> Instead of looking to introduce a hack, look to figure out how we can
> fit this ability into the design of rules. Instead of { ... } just
> containing perl6 code, we need a way to signal that it's not perl6 code.
Right. "use Python;" and "use PIR;" seem just as good as ":Python" or
":PIR" to me and have the added benefit of looking like something Perl
would do. (I'm not sure whether that's a benefit or not but it sounds
good for now :)
> >>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.
> The interface that is behind the C<compile> opcode of parrot. See
> http://www.parrotcode.org/docs/ops/core.html, near the bottom, under
> "native call interface".
Ah. Hrm. Surely the grammar engine needs to know where the "closure"
ends. Can't it just send the bit that needs compilation and basically
do a substitution?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
