[Python-Dev] Re: pirate (python+parrot)

[Dan Sugalski]

At 4:25 PM -0400 8/4/03, Michal Wallace wrote:
>On Mon, 4 Aug 2003, Dan Sugalski wrote:
>
>>  To be honest, I'd rather leave it as it is--not because I don't
>>  think that parsing python and compiling to parrot isn't worthwhile
>>  (I think it is) but because I can be reasonably assured that the
>>  conversion will take place (because I want it to happen and have
>>  wagered pie on that want, and thus will make it happen :). Besides,
>>  I'm not much of a parser guy, thus the parsing part's actually more
>>  difficult than the bytecode translation, which is reasonably
>>  straightforward.
>
>Fair enough, but have you looked at pirate?

Yep. Checked it out earlier today. A quick scan of it looks pretty cool.

>The
>parser's done. Python exposes its own parser via
>the parser module. There's a python module for
>walking that tree, and all I'm doing is calling
>that and writing methods.

You do have a significant advantage in this as you've done a lot of 
python work already, so you're familiar with the language. I'm much 
less familiar, and as such a bytecode translation's easier, or at 
least I find it easier. None of that pesky syntax to deal with. :)

>The only potential snag in the scheme is the exec
>statement, because somehow parrot's got to have a
>python parser. But unless I'm missing something
>completely, you have the same problem with your
>bytecode interpreter because there is no way
>you can do exec without a python parser. :)

True, but the original terms of the challenge precluded this, along 
with extensions written in C. I don't know if that made it into the 
final challenge--if not, I may have been outmaneuvered...

>I know you're more comfortable looking at bytecode,
>and yes, some of the translation stuff might be
>applicable to translating other stack-based bytecode
>to parrot, but it just seems like it's not really
>helping anyone.

Not strictly true. Besides the parrot infrastructure this challenge 
will force me to make sure is working, it'll be the easiest way to 
make sure that all the semantics that need to be there for Python 
will be there, so it's a good reality/design check before we go beta 
or final, depending on timing. Plus I get to pitch a pie at someone 
who may well be Guido. :-P

>I read through Klaas-Jan's entire Lua->parrot paper
>yesterday: http://members.home.nl/joeijoei/parrot/report.pdf
>and except for the for statement (which has different
>semantics in python), our generated IMCC and the problems
>we're dealing with are almost identical. That's why
>we're talking about merging the code generators.

Which is a good project, and I'm digging to those messages now. I'll 
comment more on p6i, where it's more appropriate.

>I think compiling python source to parrot bytecode is
>going to take a couple weeks AT MOST. It would go a
>whole lot faster if someone like you or Leo were
>pairing with me.

Talk to Leo, though there may be timezone issues. (He's GMT+100) I'd 
love to, though I'm pretty desperately short of large chunks of time. 
:(

>Then the tricky part is just making the bytecode run as
>fast as possible, and dealing with the built-in types,
>which is what you probably really want to be doing, right?

Absolutely.

>Honestly, the goal shouldn't be to be faster than the
>python virtual machine. Your goal should be to be to
>deliver something so compelling that the python team votes
>unanimously to dump the current VM in favor of parrot
>for python 3.0. :)

Oddly enough, that's not my goal, and never has been. While I 
wouldn't mind, it's a bit presumptuous on my part. Language 
designers, in my experience (granted, somewhat limited, I've only met 
a dozen or so) tend to want to fiddle with the software as they go as 
well, so even when Parrot runs things faster they'll still want to 
write the software to test out their ideas. As an example, if I 
handed Matz a Ruby on Parrot that ran an order of magnitude faster 
than plain ruby he'd be thrilled, and still work on his version of 
the ruby interpreter, and that's fine.

So, while I'd be happy if Guido decided that Parrot was a sufficient 
win to switch over to it as the core for some version of Python, 
that's not my goal. I'm OK with Parrot having Jython status for any 
language I can get my hands on.

>Long term, I'm imagining a situation where people don't
>really have to deal with code generation at all, except
>to override the parts that need to be customized for
>their own language. It'll boil down to generating
>an AST and then transforming the tree to fit with the
>generic compiler's worldview, and then hitting "go".
>Everything from that point on down - peephole optimization,
>calling conventions, imcc, would be standard.

That's always been the plan, though my dislike of parsing's kept it 
near the back of the list of things to do. Time to change that, I 
think. ;)
-- 
                                         Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan at sidhe.org                         have teddy bears and even
                                       teddy bears get drunk