Matt Fowles writes: > Dan~ > > I still don't see why this necessitates keyed variants of all the ops. > Couldn't we have a "prepkeyed" op which would return a specialized pmc > to use in the next op?
Yes, we could. But it would be in exchange for both speed (because we're allocating a new pmc each keyed acces) and code complexity on the Parrot side (because we have to add a level of indirection for the proxy pmc). And complex code often leads to even slower code. Op count isn't that important. In those few places where it is (embedded systems, eg.), it would theoretically possible to configure which ops had keyed variants, and convert the bytecode accordingly (at the possible expense of an extra, dedicated register as the intermediate). But that probably won't happen, because then we have to write both keyed ops and proxy ops, defeating the complexity argument. There's something to be said for this way of doing things, however. In particular, when you want eg. to tie to a database, and want things to work just like normal except for fetches and stores, you only have to overload the prepkey vtable to return a proxy pointing to a different place, instead of all the vtable. I like this proposal in general; I'm mostly worried about speed. If someone who understands what makes things fast better than I do can figure out a way to make this comparable in speed, I'd support it (probably; I'd have to think some more first :-). Luke > Thus instead of > > set P0, P1[P2] > > we would have > > prepkey P3, P1[P2] > set P0, p# > > similarly > > add P0[IO], P1 > > would become > > prepkey P2, P0[I0] > set P2, P1 > > Sorry if I am being a little slow here. But thanks for the full > explanation of active data. > > Matt
