Re: pugs and pirate
Patrick R. Michaud
> On Thu, Jul 07, 2005 at 07:52:31AM -0400, Michal Wallace wrote:
> > I'm the guy running the pirate project (python-on-parrot). Leo says
> > that you and I ought to chat, and I think he's right. :)
>
> Wonderful. Cc'ing both pirate and p6c as I'm sure both lists will
> find this discussion fruitful. :-)
Yes, yes, yes. Please continue to include p6c on the discussion,
and thanks to both of you for your work.
> If PAST ends up being a more nicely abstracted PIR-tree, I'm sure PIL
> can retarget that with ease; if you consider PAST to be essentially
> Parrot independent, maybe we should look at how PIL and your planned
> Python AST differ, and work to unify them into a single tree.
FWIW, I totally agree with this approach.
Pm
Autrijus Tang
> I'm the guy running the pirate project (python-on-parrot). Leo says
> that you and I ought to chat, and I think he's right. :)
Wonderful. Cc'ing both pirate and p6c as I'm sure both lists will
find this discussion fruitful. :-)
> Here's the deal: about a year ago, Klaas-Jan Stol (who does the Lua
> compiler) and I were kicking some ideas around ont the parrot list
> about a generic AST/emitter layer for our compilers, that could be
> used as a library or take a scheme-like syntax as input. (Leo's PAST
> implementation sprang from that, but he says it's still a proof of
> concept)
S-expression is a nice concrete syntax indeed. The existing PAST, with
node types as language-specific as "Py_Print" and "Py_Print_nl" and as
Parrot-specific as "PCC_Sub", is perhaps not well-suited as a common
ground.
> Anyway, we've got a guy with a google/perl foundation sponsorship to
> actually do this work for the summer. The plan is to factor out
> pirate's ast/emitter into something everybody can use. I've been
> looking at python, lua, and haskell (through jhc - I'm a haskell fan
> too) as use cases, but of course it would be silly not to not to get
> you involved.
That's fantastic news!
> Basically we want to make sure the Parrot AST is there and strong
> enough for you to target. :)
During my stay in Leo's, I have created not one, but two ASTs that
currently works in concert to compile Perl6 into Parrot. We can already
run our unit test with a running Test.pm module compile to Parrot.
One is PIL, the Pugs Intermediate Language, with 14 node types, listed
at the top of http://svn.openfoundry.org/pugs/src/Pugs/Compile.hs as
GADT constructures:
PNil :: PIL [a]
PNoop :: PIL Stmt
PVal :: Val -> PIL Literal
PVar :: VarName -> PIL LValue
PExp :: PIL LValue -> PIL Expression
PLit :: PIL Literal -> PIL Expression
PThunk :: PIL Expression -> PIL Expression
PCode :: SubType -> [TParam] -> PIL [Stmt] -> PIL Expression
PStmt :: PIL Expression -> PIL Stmt
PStmts :: PIL Stmt -> PIL [Stmt] -> PIL [Stmt]
PApp :: TCxt -> PIL Expression -> [PIL Expression] -> PIL LValue
PAssign :: [PIL LValue] -> PIL Expression -> PIL LValue
PBind :: [PIL LValue] -> PIL Expression -> PIL LValue
PPad :: Scope -> VarName -> PIL LValue
Another is a tree form of PIR, defined as Haskell data type in:
http://svn.openfoundry.org/pugs/src/Emit/PIR.hs as well as a set of
Parrot objects in http://perlcabal.org/~autrijus/pir.txt (the emitter
is currently only available in the Haskell side, but shouldn't be hard
to port over to C or PIR).
With the trunk version of Pugs, you can generate PIL and PIR in the
command line like this:
./pugs -CPIL -e '...' > dump.pil
./pugs -CPIR -e '...' > dump.pir
PIL corresponds closely to desugared Perl6, and hence is not
Parrot-specific at all; PIR corresponds closely to desugared PIR, and
hence ties closely to the Parrot architecture. I wonder which level
do you expect the "Parrot AST" to resemble most?
Anyway, that's what we have at this moment. Pugs's aim is comparable to
PyPy's -- i.e. a complete Perl 6 implementation in Perl 6, with parser,
semantic analyzer, standard prelude and the object space. Depending on
the target platform, it is my hope that PIL can be transformed further
into ANF/SSA or other AST forms for optimization.
If PAST ends up being a more nicely abstracted PIR-tree, I'm sure PIL
can retarget that with ease; if you consider PAST to be essentially
Parrot independent, maybe we should look at how PIL and your planned
Python AST differ, and work to unify them into a single tree.
Thanks,
/Autrijus/