On Fri, Sep 06, 2002 at 12:47:11AM +0200, Leopold Toetsch wrote: > Steve Fink (via RT) wrote: > > ># New Ticket Created by Steve Fink > ># Please include the string: [perl #17039] > ># in the subject line of all future correspondence about this issue. > ># <URL: http://rt.perl.org/rt2/Ticket/Display.html?id=17039 > > > > Why intarrary.pmc: > > >+=item B<push>(in PMC, in PMC) > > ... > > > >+=item B<push>(in PMC, in INT) > > > There are already very useful arrary operations, which are currently > used in e.g. embed.c namely "push_string" and these don't have an opcode.
Now they do. push(in PMC, in STR) calls exactly that vtable entry. > perl6/P6C array flattening code would be cut down by ~2/3, when this > opcode is implemented (push ..) And this patch implements them. Unless I'm misunderstanding what you're saying. > I see a forthcoming pollution of core.ops namespace. I think it is reasonable for all of the vtable entries to have their own opcodes. I think you may be misunderstanding something here -- those new push/pop/shift/unshift instructions in core.ops are in no way specific to the IntArray PMC. They work equally well for the current Array and PerlArray PMCs. push(PMC, STR) just calls $1->vtable->push_string(...). > And I can't imagine (now at 0.40pm ;), we need a third array class - but > I didn't read the patch. Speed and space. This is intended to replace the special-purpose intstack currently in the Interp struct. They both provide a fast, integer-only stack. intarray.c is just a modified version of rxstacks.c, but I don't think rxstacks.c does anything that intarray.c cannot do. But that's the underlying data structure. Your question was why we need another array class (PMC). Two reasons: 1. My regex implementation doesn't use anything specific to regexes in Parrot (i.e., no rx_* ops, no special-purpose data structure embedded in the interpreter struct, and no intstack_* instructions.). So to get a fast integer stack that I could have more than instance of per interpreter, I needed to make it a PMC. 2. Part of the Perl6 design was to allow space-efficient versions of some data structures. For example, you can declare an integer-only array. This is the PMC that would hold it. (Maybe. It's really a dequeue, so indexed lookup requires linear rather than constant time. But I bet it would be easier to modify intarray to support arbitrary sized chunks of arrays than it would to write a new integer-only linear array that supported fast shift/unshift.) > One array base class doing it, ought to be enough. So why doesn't this > fit in array.pmc, which PerlArray does reuse? It could extend array.pmc, except that at least right now there is nothing in array.pmc that it could usefully inherit. It has the same *interface* as array.pmc -- but the only programmatic interface that we've defined is the vtable, and that's the same for all PMCs. Or, in other words, the implementation of intarray.pmc is so different from the implementation of array.pmc that no useful _implementation_ inheritance exists. I guess I really ought to rename it IntDequeue, since it really is a different data structure than Array and PerlArray. It's just that "dequeue" is impossible to type. And I suspect Array/PerlArray will change to look more like intarray, when we realize we need to support fast shift/unshift. (As opposed to right now, when we don't support them at all!) How about IntList? Anyone have a problem with that name? > Minor note: todays in/inout conclusion is currently :-) "inout". So should it be push(inout PMC, in INT)? And pop(out INT, inout PMC)? Thanks for the comments.
