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? It doesn't matter. At runtime we end
up with:
pmc->vtable->add_int() # example below
whatever the PMC is. When it's kind of a scalar, it will support the
operation. When it's a PerlArray you get:
add_int() not implemented in class 'PerlArray'
I don't see a reason, why
new P0, .PerlArray
add P0, 1
should be meaningful or supported--or much worse:
shl P0, 31
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.
> Separate functions, separate entries. I already made the mistake of
> trying to overload some of the other entries in the past. We've fixed
> that up and I'd rather not do that again.
That's reasonable of course, but I don't see why we just can define:
- an Arrays vtable slot for scalar operation C<op> means C< »op« >
But this still means that
add P0, 1
is an error - because the C<hyper> prefix is missing.
> Yeah, having hyper versions of the ops does blow out the opcode list
> a 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
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])
The C<hyper> prefix pvovides the map part and the needed environement
and then calls the appropriate vtable (for PMCs) to do the actual work.
> ... 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.
AFAIK is Perl6 the only language that provides these hyper ops so we
should support these efficiently, especially with natural types.
leo
