Jeff Clites <[EMAIL PROTECTED]> wrote: > On Apr 21, 2004, at 9:05 AM, Leopold Toetsch wrote:
[ just another f'up to separate items ] > So are you saying, have separate vtable slots for the hyper operations, > but then you only have to fill in the vtable->hyper_add() slot _if_ you > want it to do something other than applying vtable->add() in a loop > (otherwise, do what your proof-of-concept did)? If so, that makes a lot > of sense to me. We have: Parray->vtable->add ... unused and it's never used in an hyper loop (given that aggregate elements aren't arrays by themselves). Hyper-add for PMCs just calls Pelem->vtable->add ... scalars have it on each aggregate member. The Parray->vtable->add slot is still unused and will give you the "unimplemented" exception. But if a class inherits from PerlArray, it can override Parray->vtable->add ... delegated, ok and use it as the hyper-add operation. The idea is that hyper .ADD, args # or hyper \n add args or whatever the syntax really is, works as an operator prefix. The C<hyper> prefix inspects the operation and dispatches either directly to the overriden vtable or runs its own map-like loop. The latter can call an appropriate vtable or rolls its own optimized version for natural types. > On the other hand, from what's been said it sounds like Perl6 may not > intend to allow you to override a hyper op independently. I don't care and mathematicians will like to be able to override e.g. »*«. > ... If so, we > don't need the separate slots, it seems, but we do need a > vtable->hyper() which somehow takes an op as a parameter, since only > the PMC itself know how to get at its "logical contents" as a > container. C<hyper> per se isn't an operation. It's a do "these sequence of operations with ..." prefix. Keeping the prefix notation inside just keeps that logically consistent. > ....time passes.... > ... but rather as "hyper-apply > 'add' to...". That is, if the syntax had been something like: Hah. Same thoughts. Yes. > array.appleToEachElement(&add, 1); Yep. And that's exactly what I try to achieve. Without +1000 additional opcodes and (~50) vtables. > then there wouldn't be any temptation to think of >>+<< as a separate > operator. The C<+> operator is never applied to the array. It's always for the elements. C< »+« > isn't an opcode, that's it. It doesn't need a vtable, it doesn't need multiple implementations, all with the whole loop around ever and ever repeated. > That is, have a "hyper-wrapper" PMC, which knows how to hyper-apply any > op to the PMC it's wrapping. That *is* an interesting idea. It could hide some of the ugliness of my approach. OTOH the usage of that hyper-PMC is a bit clumsy, reading the code doesn't really get you what's happening: hyper # ok we do hyper add add P0, 10 or .param pmc h add h, 10 # what's that - h like hyper or not? > This would let us avoid a bytecode syntax in which either an op > modifies the meaning of an op later in the stream, or an op needs to > take another op as a parameter. There is already one op (wrapper__) that executes another op ;) But anyway, C<hyper> does modify the behavior of e.g. C<add>, so I don't have a problem with implementing it exactly like that. > ... This hyper-wrapper PMC would then be > the only thing which needs to know about hyper-ness (I think), Yes. Including delegation. All transparent. But the drawbacks are in situations like passing such a PMC around. > JEff leo
