develooper Front page | perl.perl6.internals | Postings from July 2002

Re: Tasks for the interested

Thread Previous | Thread Next
John Porter
July 9, 2002 08:11
Re: Tasks for the interested
Message ID:

Dan Sugalski wrote:
> John Porter wrote:
> > I assume (but I'm open to correction) that it is *not* to simulate
> > the vm of other language environments, so as to execute faithfully
> > bytecode produced in those environments.  (That is, taking object
> > code from a python compiler (e.g.) and executing it in our own vm.)
> Actually, that's one of the purposes.

Oh, I hope not.  I don't believe that this could be remotely
feasible, except maybe -- *MAYBE* -- for languages whose
machine semantics are similar enough to Perl's.  Like maybe
Python and Ruby.  Otherwise, you're talking about essentially
cramming multiple distinct virtual machines into one.

This problem would probably be ameliorated somewhat by the fact,
if it were a fact, that all the machines in question are stack-
based.  But because Parrot is going to be "different", the 
problem remains unameliorated.

Another issue is the internal object model.
One common (stack-based) language I know of has opcodes for
pushing/popping individual fields of an object on the stack.
Not by name, but by index. (They're ordered.)

Then there's the semantics of GC.
Every language does it differently.

Seems to me we'd have a much better time of it, developing
new front ends for the languages we want to support, simply
targeting a different vm (parrot).  That's the approach
taken in .NET, and I think it makes sense.

(If this has been argued about before, pointers into the archive
would be gratefully received.)

John Douglas Porter

Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About