Robert Spier <[EMAIL PROTECTED]> writes:
> > The goals are to assign permanent numbers to the opcodes. What the > > numbers are is generally irrelevant, but they must be constant across > > all systems for the lifetime of parrot. > > At first glance, gut reaction, that seems "really hard"(tm) and > "really limiting"(tm)...
Why is it hard? If we have a native interface and a well designed set of basic opcodes, what else do we need?
My opinion on this has not changed in 2 years of Parrot. I see no benefit to writing a VM if we are going to allow all these "added" opcodes.
Only if the opcode libs are implemented in pure Parrot, where they can be packaged along with the bytecode file, do I see a real win for us, but even then, I can't understand why they should be ops rather than subs or such. I'm afraid we will just end up with the Perl5 situation where so many modules require C to build and install, and we are also making the VM more and more complex.
I've asked this before: Please, someone give me an example where a dynamic opcode lib gives us something that a well designed set of core ops and an extension interface does not.
Please also include in your example the semantics of packaging a portable bytecode.
-Melvin
