[etoys-dev] Parrot? (Introductions)

[Edward Cherlin]

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.

>  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.

>  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.

>  If this was about implementing the Squeak VM on Flash, that would
> have made more sense.
>
>> After we have a functioning version, we should investigate whether any
>> Smalltalk VM features can be replaced by or integrated with Parrot
>> features. Parrot provides garbage collection, concurrency, hooks for
>> an object class system, and an assortment of other high-level
>> features,

OK, here is where we can consider a rewrite.

>> 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. The question is whether it is
worthwhile having an environment in which multiple dynamic languages
with or without object class systems can interoperate safely.

> -- Yoshiki
>
> _______________________________________________
> etoys-dev mailing list
> etoys-dev at squeakland.org
> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>



-- 
Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name
And Children are my nation.
The Cosmos is my dwelling place, The Truth my destination.
http://earthtreasury.org/worknet (Edward Mokurai Cherlin)