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.
>
>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. That doesn't mean that you
can't do things to make something easier, however.
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.
Besides, what makes you think we won't be doing at least some class of subs
this way? :)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
