Dan Sugalski writes:
: At 03:08 PM 4/25/2001 -0300, Branden wrote:
:
: >At 01:52 PM 25/04/2001 -0400, Dan Sugalski wrote:
: >>Seriously, I don't see why this should be a scary thing. So, the opcode
: >>table's extendable. So what? It'll make language X mode simpler, for some
: >>value of X, if that language can load in its own set of extended opcodes.
: >>Perhaps someone'll want to do functional programming with the Parrot
: >>runtime, and it makes the most sense from a speed and parser simplicity
: >>standpoint to treat certain activities as atomic things and emit a single
: >>bytecode for them. Extending the opcode table makes sense there.
Possibly, but I just looked through the opcode table, and found only
about 50 opcodes that weren't obvious candidates for OO treatment.
Which basically means that the other 300 or so of them *are* candidates,
and don't belong in the opcode table at all.
: >I agree, although I would argue that for functional programming you don't
: >need anything but Perl
:
: Oh, sure, that's true and I'll give no argument.
We don't have continuations yet...
: That doesn't mean that you
: can't do things to make something easier, however.
We just need to be careful that in making something easier we don't make
something else much harder. Those 300 non-opcode methods still need to be
blazing fast...
: You could, for example, argue that perl has no real need at the C level for
: opcodes with underlying support for arrays and hashes as data types, as you
: can emulate them with the scalar operations. Doesn't make them any less useful.
:
: >Anyway, I would say opcode extendability should be analysed with a ROI
: >optics, because I really don't know if having new opcodes (instead of
: >faking them with subs -- if we have appropriate ways of locking &
: >synchronizing thread data) would be really necessary.
:
: Providing the capability is simple and straightforward, and will piggyback
: on top of the overridable opcode stuff.
Just make sure it's lexically scoped so my new opcodes don't clobber yours.
: Besides, what makes you think we won't be doing at least some class of subs
: this way? :)
Why not all of them? Why not simply say that opcodes and subs are
indistinguishable in how they're stored in the symbol tables? Some
subs may be implemented in Perl, some in C, some in Java, some in C#,
some in P4 assembler...
Larry
