Dan Sugalski <[EMAIL PROTECTED]> wrote:At 10:55 PM +0200 4/20/04, Leopold Toetsch wrote:
Do you want to reserve these just for implementing perl's scalar context of arrays or hashes, or is there more behind the scene?
More behind the scenes. (Though that's a good reason too) The problem is that we've got quite a few cases where we can't tell at compile time what the heck's going on with a PMC, so there's no good way to know if it's an aggregate or a scalar. If we overload the vtable entries we're going to get into trouble.
I don't get that. Why should we need to know at compile time, if we are dealing with an aggregate or not?
So we know what we're doing.
There are really three functions here:
1) Access PMC as a single element 2) Access PMC as a collection of elements 3) Access an element of the PMC
#3 is done with the much-maligned operation_pmc_keyed vtable entries
#1 is done with the plain operation_pmc vtable entries
#2, which corresponds to the hyper operation, doesn't have a spot in the vtables.
I'm drawing the distinction between an operation on the container and an operation on all the container's contents here. I think it's the right distinction.
With separate vtable entries, you'll either have to duplicate the whole MMD slots, with one extra indirection for vtable->hyper->func, or overloading is an all or nothing operation. Both is suboptimal.
The extra indirection for hyper ops isn't a big deal. The operation itself should take long enough that the indirection's lost in the noise,
> Yeah, having hyper versions of the ops does blow out the opcode lista lot, but the alternative is to end up with a half-assed system that'll have the math guys down on my head. I'd as soon skip that one. :)
We don't need a hyper version of each opcode, if we go with the scheme I've proposed, either
hyper op args
or maybe
hyper .OP, args
I dunno. It's awfully early to be wedging in hacks--we ought to at least wait until we've hit 1.0...
Such a scheme also fits nicely with Luke's summary (thanks BTW) that is:
@a »op« @b
always means
map { $a[$_] op $b[$_] } 0..max([EMAIL PROTECTED], [EMAIL PROTECTED])
I think we'll find that if we
> ... I'm OK with putting limitations on it--pmc-only, for example,so we don't have to deal with S/I/N versions of the hyper ops.
PMC-only means, that you'll always have to call e.g. get_integer on the PMC, because the PMC might be tied. This limitation isn't really good for performance reasons. People might use it most likely in combination with natural typed arrays.
What I'm saying is that if someone does:
$foo >>*<< 1
that the 1 is a PMC, rather than a low-level integer, in an attempt to reduce the number of ops in the core and slots in the hyper vtable.
This is an efficiency limitation. I'm willing to give it up and go the full route, but that'll make the optable somewhat large. (OTOH we can stick 'em all in hyper.ops, I suppose)
AFAIK is Perl6 the only language that provides these hyper ops so we should support these efficiently, especially with natural types.
I think we're going to disagree on which way's efficient here. -- Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
