push_integer() not implemented in class 'FixedPMCArray'
Austin Hastings
Austin_Hastings at Yahoo.com
Wed Sep 9 13:36:27 UTC 2009
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<jaleto at gmail.com> 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.
>
>
More information about the parrot-dev
mailing list