Parrot has opcode versions of ppsu (push, pop, shift, unshift) for a
reason - opcodes are faster than method calls, and we expect these
operations to be very frequently executed.
Presently, according to the OP, the Fixed* PMCs don't support the ppsu ops.
Obviously, then, nobody is using them in that way.
Adding ppsu would make PVM "more complete", but it probably wouldn't
change the way people are writing PIR - old habits, etc.
So the likely "beneficiary" of this would be hll implementors (like me!)
who might use Fixed instead of Resizable if they could.
A fair number of hll's are "wrapping" PMCs in their own types, so it's
not clear how much benefit there is to be had.
Ask pmichaud, "Does Rakudo care about Fixed* arrays?"
=Austin
Andy Dougherty wrote:
On Tue, 8 Sep 2009, Theodore Reed wrote:
On Mon, Sep 7, 2009 at 19:08, Jonathan Leto<[email protected]> wrote:
Howdy,
Should one be able to push up to a fixed number of elements onto a
FixedPMCArray?
Now, I realize that I may be newish here, so forgive me if I'm talking
completely out of my ass, but to me the idea of pushing/popping or
shifting/unshifting a Fixed anything seems like it's just
inappropriate; the very notion of these operations implies a change in
the size of the Array.
My expectation is completely the opposite. HP calculators that use
"Reverse Polish Notation" have a fixed-size "stack", and the manuals use
the phrases "push" and "pop" for manipulating that stack. If you "push"
too many things on, the oldest thing just gets thrown away. When you
"pop" things off the stack, the oldest entry just gets copied down.
It all seems very intuitive to me, but then I've been using that type of
calculator for over 30 years, so I may be just a little set in my ways.
In any case, there definitely is at least one well-defined very-workable
existing example of supporting the concept of pushing onto a fixed array.
I'm guessing that from your text above, you intend the implementation
to permit exactly five pushes before... what? An exception is thrown?
I'd think you could keep pushing as many things as you want, but the
Fixed array would only hold the last 5 elements pushed.
You'd need to track how far things have been pushed, and maybe even
the "has_been_set" status of every element.
What happens in the following situation?
(let 'U' stand for an undefined garbage value here)
(I may also have the array order backwards; perl 5 "pushes" on from
the right, so that's what I assumed here.)
new $P0, 'FixedPMCArray'
$P0 = 5
@P = (U, U, U, U, U)
$P0[2] = 1
@P = (U, U, 1, U, U)
push $P0, 2
@P = (U, 1, U, U, 2)
push $P0, 3
@P = (1, U, U, 2, 3)
push $P0, 4
@P = (U, U, 2, 3, 4)
And are you going to do all of push/pop/shift/unshift? Then you'd need
to track from both sides, in interesting ways. (How would successive
pops even be handled if you're not removing things?)
Here's how I'd think things should pop: (I don't know the correct pop
syntax off the top of my head):
new $P0, 'FixedPMCArray'
$P0 = 5
push $P0, 1
push $P0, 2
push $P0, 3
push $P0, 4
push $P0, 5
# @P = (1, 2, 3, 4, 5)
pop $P0
# @P = (1, 1, 2, 3, 4)
pop $P0
# @P = (1, 1, 1, 2, 3)
pop $P0
# @P = (1, 1, 1, 1, 2)
pop $P0
# @P = (1, 1, 1, 1, 1)
I'm just not convinced that these operations make any sort of sense in
the context of a Fixed-size Array.
I think they can make perfect sense. Whether they are worthwhile to
implement in parrot is, of course, a rather different question.
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
