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 http://sbc.yahoo.com
