At 05:41 PM 4/30/2001 -0700, Larry Wall wrote:
>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.
That's fine. Pretty much everything that's not control flow or modifies the
interpreter environment should probably go in the vtables.
>: >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...
But there's nothing at the lowest levels of the interpreter that prevent
that. You could, if you chose, get a stream of bytecode that would do you
continuations. Slowly and awkwardly, perhaps, but still do them. (I'm all
up for doing them better in perl 6)
>: 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...
And the dispatch to them needs to be fast, and the opcode loop needs to be
fast... I think I sense a trend, here. :)
>: 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.
The opcode dispatch table will probably be lexically scoped and
thread-private.
>: 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...
Because the opcode subs will have different required characteristics than
the vtable ones, both of which will likely be more restrictive than what
you have for plain subs. Which is to say you could call a vtable sub as a
regular sub, or an opcode sub as a regular sub, but not a regular sub or a
vtable sub as an opcode sub.
And yes, I do want them indistinguishable (more or less) from subs written
in C, or assembly, or Java, or whatever. That's going to require a bit more
platform-specific work on the part of each port than we currently require,
unless someone cleverer than I am can set me straight. (I can't think of a
good way that doesn't require generating function header code on the fly)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
