Syntax for PAST Optimizations

chromatic chromatic at wgz.org
Tue Jun 1 14:58:59 UTC 2010


On Monday 31 May 2010 at 07:54, Patrick R wrote:

> Ah, more directly (again I'm just brainstorming with some P6 syntax):
> 
>     class FoldAddition {
>         multi method fold(PAST::Op $/ where $/.pirop eq 'add'
>                                             and $0 ~~ PAST::Val
>                                             and $1 ~~ PAST::Val) {
>             PAST::Val.new( :value( pir::add($0.value, $1.value) ) );
>         }
>         ...
>     }
> 
> Or, more generally to handle constant folding for many common pirops:
> 
>     class FoldConstants {
>         multi method fold(PAST::Op $/ where $/.pirop
>                                             and $0 ~~ PAST::Val
>                                             and $1 ~~ PAST::Val) {
>             PAST::Val.new( :value( pir::{$/.pirop}($0.value, $1.value) ) );
>         }
>         ...
>     }
> 
> No, NQP doesn't support where clauses in multimethod dispatch yet
> (Parrot multi dispatch is type-based by default instead of constraint-
> based).  
> 
> However, it's entirely possible that a library could be developed for 
> Parrot that would allow constraint-based multimethod dispatch, which NQP 
> could then take advantage of (or perhaps even provide, similar to how it
> currently provides regex capabilities).  Early versions of Rakudo were able 
> to do this type of multidispatch to some degree on top of Parrot's existing 
> subroutine dispatch, before Jonathan went and redesigned it entirely (to 
> support a large number of other needed semantics).

I've long thought about two design approaches:

	* a declarative syntax for matching nodes and branches
	* an event-based system to perform transformations

In other words, you write the match conditions in a little language (whether 
that's a syntax like Allison's or a variant of XPath or Perl 6 Signature style 
syntax).  The language itself registers event handlers which specialize on 
various criteria (every PAST::Val, or every PAST::Op with two children, 
or....).  The optimization runtime traverses the tree and dispatches events 
for every applicable node.

If written right, this can avoid the TGE problem where handlers had to 
dispatch their own children.

Even so, getting the optimization language ideal (or at least, correct) is 
beyond what I expect from Tyler as part of his project.  If his design works 
out well, we can modify that language as necessary; it's just matching nodes 
and branches.

-- c


More information about the parrot-dev mailing list