----- Original Message -----
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Tuesday, September 14, 2004 3:56 pm
Subject: Re: Current state?
> On Tue, Sep 14, 2004 at 12:42:59PM -0700, Larry Wall wrote:
> > : Of course, this is really language design -- Larry, you listening?
> >
> > Sure, I'm listening, but what's the point when I agree with
> everyone. :-)
> >
> > I agree that the default should be the current outer language.
> > I agree that the default ought to be overridable.
> > I agree that the right way to do that is with something like
> "use PIR;"
> > rather than inventing an inconsistent syntax.
>
> This will likely betray some deep ignorance on my part (and this
> discussion may have taken place already elsewhere), but since I'm
> currently working on a rules syntax parser I'll barrel forth
> anyway:
>
> What should the mechanism be for the rule parser to figure out
> where
> a closure begins and ends within a rule expression? Does the rules
> parser have to call the outer language compiler directly?
Since a closure can contain arbitrary Perl6 code, yeah. But I was under the
impression that parsing the rules themselves needed to be done by the outer language
parser just because of that jazz. Maybe the outer language parser could parse the
rule first, and then replace language-specific constructs with stubs or the body of a
PIR sub:
rule rules {
$rules := (rules) { for 1..5 { print "$rules totally rule.\n" } }
}
And, after the outer language Perl6 compiler gets done with it, the Rules Engine would
see:
rule rules {
(rules) {
.param MatchObject match
set $I1, 1
new $P0, .PerlString
set $P0, " totally rule."
L_1:
new $P1, .PerlString
clone $P1, match["1"]
concat $P1, $P0
print $P1
inc $I1
le $I1, 5, L_I
}
}
And then it would be easy to find the end of the closure construct since it will
contain plain ol' PIR.
> If so, does this imply that the rules parser has to be running in
> Parrot to be able to call the outer language compiler, or is there
> a
> way to do this from C?
>
> And does the outer language compiler have to have options that
> allow the caller to say: "hey, here's some program code with
> perhaps
> a bunch of rule-syntax stuff appended to it, could you just give
> me
> back the first complete 'closure unit' and oh, by the way, tell me
> how
> many characters you used to do it or give me the left-over string so
> I can continue parsing my stuff?"
Well, you could always design the compiler so that it can be put into a special mode
that:
- recieves the raw text as an argument
- tries to parse a whole block from that (e.g., starts at rule "block" instead of rule
"prog")
- if successful, compiles that block into a closure PMC and modifies the raw text by
deleting the parsed text from the start of it. (kinda like
Parse::RecDescent::Consumer)
- returns the closure PMC and the modified text
> Or is there some syntactic shortcut that can be made to let us find
> the end of a closure without having to fully parse the closure itself?
>
> How does p5 do it?
p5 just tries to find a balanced set of curlies.
> (And you can see why I've been willing to postpone true closures
> in
> rules just a bit longer until we got a p6 compiler started. :-)
Oh, definitely, definitely. :)
- Joe
