Re: Current state?

[James Mastros]

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.  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. 
 I think the way to do that is by following the open curly with a 
colon, and the name of the language, which should match <identifier>. 
Everything that after that identifier is taken to be in the language 
named.  If there is no colon, the language is assumed to be 'perl6'. 
(Note that this implies the actual code always starts with a single 
space for non-perl6 code, and that you have to play games if the perl6 
code is supposed to begin with a colon -- but all there any valid and 
useful uses for such code?)

Of course, this is really language design -- Larry, you listening?
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".

- 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.
I think that's the case here.
	-=- James Mastros