Support for S05's new "result object"?

[Audrey Tang]

Heya. Today I noted with delight that PGE supports interpolation of
closures:

$ parrot demo.pir
rule Foo {{ print "Hello" }}

Though the Perl 6 form is {...} instead of {{...}} -- is that intentional?

We have started self-hosting Perl6 compilation, beginning with a
self-hosting Rule engine; to construct the AST object, we use the
"return" form recently specified in S05.pod. Please see
http://perlcabal.org/~gaal/peek/slide37.html for an illustration of its use.

In a nutshell, the Match object can now function as a Code, and when you
call it (via $match() or $() or coercion), it yields the match "result
object". By default this is just the string (~$/), but one can set the
result object inside the rule with this syntax:

rule { Ferrari : { return Car.new(:color<red>) } }

This alleviates the need for an attribute-grammar pass to convert match
objects into ASTs, and allows selective parsing of subrules based on
querying earlier subrules' result objects.

Is it possible for PGE, with its embedded code closure, support
something like that? For example, make a lexical symbol RETURN
visible inside the interpolated block, which will set the result object
and return a match success at that position?

rule Foo {{
$P0 = new .Some::Tree
RETURN($P0)
}}

If available, this will greatly help Pugs to bootstrap its Haskell parts
off to Perl 6, as it allows us to translate the parser-combinator style
parsing into equivalent Perl 6 rules.

Pointers to where in the PGE source to hack this together would be
appreciated. :-)

Thanks,
Audrey

[Patrick R. Michaud]

On Wed, Mar 15, 2006 at 06:50:53AM +0800, Audrey Tang wrote:
> Heya. Today I noted with delight that PGE supports interpolation of
> closures:
>
> $ parrot demo.pir
> rule Foo {{ print "Hello" }}
>
> Though the Perl 6 form is {...} instead of {{...}} -- is that intentional?

Yes, it's intentional. PGE uses a generalized form of {{...}}
for generic closures in any target language, as mentioned by
Larry in a post from last summer. We're reserving { ... }
for the specific case of Perl 6 closures (where the embedded
code is parsed as Perl 6 code), but PGE allows any target
language to be embedded in a rule by using {{ ... }}.
Or, if the embedded closure itself needs to double braces
for some reason, then the rule can use {{{...}}}, {{{{...}}}}, etc.,
similar to how POD handles <<<...>>>.

So, one can have

rule myrule :lang(PIR) { <token> {{
I0 = match
I0 *= 2
print I0
}} }

and the embedded PIR "closure" will be executed after the
<token> subrule is matched. The :lang() modifier can have
any compiler that Parrot's "compreg" instruction understands.

> We have started self-hosting Perl6 compilation, beginning with a
> self-hosting Rule engine; to construct the AST object, we use the
> "return" form recently specified in S05.pod. Please see
> http://perlcabal.org/~gaal/peek/slide37.html for an illustration of its use.

I haven't had a chance to fully look at the change to S05, so
give me a day to look it over and I can respond more intelligently
about how quickly we can get PGE to support the changes.

> Is it possible for PGE, with its embedded code closure, support
> something like that? For example, make a lexical symbol RETURN
> visible inside the interpolated block, which will set the result object
> and return a match success at that position?
>
> rule Foo {{
> $P0 = new .Some::Tree
> RETURN($P0)
> }}

But in answer to your question, for :lang(PIR) PGE already
puts a nice pre-amble around the PIR code and makes the current
match state available as a "match" symbol, so it seems like
it ought to be possible to do what you're describing here.

> Pointers to where in the PGE source to hack this together would be
> appreciated. :-)

Take a look at the closure.t tests in t/compilers/pge/p6rules,
and at the PGE::Exp::Closure object at the bottom of
compilers/pge/PGE/P6Rule.pir to see how PGE is currently
handling it.

Also, I should be able to start hanging out on #perl6
on a regular basis again, so you can ask questions of me then.
I'll make a point to be available tomorrow morning
(probably around 1500 UTC).

Thanks!

Pm