[etoys-dev] Parrot? (Introductions)

[Yoshiki Ohshima]

At Sat, 11 Jul 2009 23:47:26 -0700,
Edward Cherlin wrote:
> 
> On Sat, Jul 11, 2009 at 11:03 PM, Yoshiki Ohshima<yoshiki at vpri.org> wrote:
> >  Edward,
> >
> >  Sorry for replying to an introduction email but...
> 
> No, I meant for people to comment.
> 
> > At Fri, 10 Jul 2009 11:34:33 -0700,
> > Edward Cherlin wrote:
> >>
> >> o I am also talking with Allison Randal, head of the Parrot project,
> >> about various projects. She told me that she would love to have a
> >> Squeak for Parrot. (Right now, they only have their toy language
> >> Squaak. No relation. ^_^). This means compiling the Smalltalk VM for
> >> Parrot. But that means getting a C compiler to generate Parrot
> >> assembler. I don't know how far along that project is.
> >
> >  Hmm... Why not compile Smalltalk to Parrot bytecode?
> 
> Is there a difference? Actually, I may be wrong. It may be that the C
> compiler will generate PIR, Pirate Intermediate Representation. But
> that doesn't matter, since it all ends up as byte code.
> 
> If you think it would work better to have Smalltalk translate the
> Smalltalk VM to PIR rather than to C, that's fine, too. But the PIR
> compiler includes register optimization, which I don't think you want
> to rewrite.

  The difference I have in my mind is whether there would be two
interpretation layer or one interpretation layer.  

  Now, I wonder if you use "Smalltalk VM" in a different sense.  I
wasn't saying what the compilation target should be.  Sure, it can be
to PIR or bytecode.  What I was saying was what to compile; it should
be user Smalltalk code and not the VM.  You may be referring to the
fact that the Squeak VM is written in Squeak; but it goes through the
C compiler and produces somewhat the similar layer to Parrot.  I don't
think we gain something if we layer them.

> >  But, however, the real strength of Squeak for us has been that the
> > same program runs pixel-identically on various platforms; so that a
> > developer who doesn't want to deal with Linux or Sugar can have
> > reasonable assumptions of his program when developing on other
> > platforms.
> 
> Fine. That's what I meant for you to do. Compile the existing C
> version of the VM, just as for any other processor.

  Sure.  I think I have done fair share of it^^;

> >  This is because Squeak VM provides all graphics and user input and
> > socket and etc (in addition to garbage collection, concurrency, a meta
> > system).  (Yeah, a virtual machine should be a machine just happens to
> > be a virtual one; so not just instruction emulation, it should provide
> > such things).
> >
> >  Parrot doesn't offer such abstraction, as far as I can tell.  If we
> > are to provide a such layer, we need to write platform specific
> > implementations for these features (as Squeak VM does) and that would
> > mean that we need to re-do whole a lot of work just to be at the same
> > place.
> 
> You are getting ahead of yourself. I said to compile the existing VM.
> Reimplementing is below, and only if it turns out to make sense.

  The code for existing VM includes the platforms specific code, for
graphics and event handling, etc.  You just need them to run Squeak.

> >  If this was about implementing the Squeak VM on Flash, that would
> > have made more sense.

  I think this should be reiterate, if Parrot is taking seriously.

> >> and is intended to allow dynamic languages to run unchanged
> >> on more than 200 hardware/OS combinations.
> 
> >  Wow.  Is there the list of these 200 combinations?  I'd be happy to
> > be surprised, but I have a feeling that Squeak VM has a bigger list...
> 
> Intended, Yoshiki, not implemented. Current targets are Linux x86 and
> ARM, Mac x86 and ppc, and Windows x86. Others will be done by whoever
> wants them badly enough.
> 
> The question is not whose is bigger.

  Sure, then why did you bring up an arbitrary number like 200?

> The question is whether it is
> worthwhile having an environment in which multiple dynamic languages
> with or without object class systems can interoperate safely.

  Yes, but Squeak VM on-top-of Parrot VM doesn't gain much, we
wouldn't even get the interoperability.  If we make a Squeak object be
a Parrot object by compiling Squeak user code to Parrot code, we could
gain inter-language interoperation.  If we compile Squeak VM to
ActionScript, we lose performance but gain virtually zero install
platform in browsers.  If we re do the entire system from Scratch, the
code should be abstract enough so that it can be mapped to Parrot.

  So, I think *if* we do something with Parrot, it should be a new
implementation, and not take existing pile of fragilely built, Squeak
specific implementation.

-- Yoshiki