Odd behaviour of ResizableWhateverArray PMC's

[Martin Kealey]

I decided that as my first contribution to Parrot I would work on rewriting
some tests as PIR, especially those for PMC's. First up was
ResizableIntegerArray, which wasn't too hard, but I noticed some things
weren't being checked.

In particular, I noticed that it wasn't checking that expanding the array
zeroed-out the intermediate values, so I added that check.

And it failed.

And thus began a debate: some hold that it's only a "low level buffer" and
that initialization isn't guaranteed; others (like me) hold that this breaks
a fairly fundamental guarantee.

The claim that it's "low level" and therefore it should be "uninitialized
because it's faster" doesn't fit with it being an arbitrarily resizable (*1)
array. A primitive operation like "push" can take O(n) time to complete
because it may result in the entire array being block-copied in memory. So
complaining about potentially taking O(n) time to arbitrarily resize doesn't
make sense.

It's also inconsistent with ResizablePMCArray, ResizableBooleanArray and
ResizableStringArray, which *do* reinitialize elements when the array is
resized.

>From a more pragmatic angle, I doubt that any language implementer will be
able to use this PMC as-is, and that if they use it at all, they'll either:

(a) not use the arbitrary resizing, or
(b) extend the PMC to initialize upon extension.

Which I guess argues for having *two* core PMC's:

 * IndexedIntegerQueue -- supports push, pop, shift, unshift, truncate,
   elements, and maybe even splice, but doesn't support setting an arbitrary
   length; and

 * ResizableIntegerArray -- as per current PMC, but with a guarantee
   that unset elements are always zero.

Then I looked at ResizableFloatArray; turns out it would fail an equivalent
test. (Moreover, putting random bits in a FP hardware register can raise
SIGFPE on some systems, so "low level" really starts to seem out-of-place
there.)

I contend that we should extend the current resizable arrays to include
zeroing out unassigned elements, and if a faster "indexed queue" PMC is
wanted, it can be built later.

What does everyone else think?

-Martin

(*1: If the only way to extend such an array was by push and unshift, then I
wouldn't have a problem, because there would be no way to create
uninitialized cells. Alternatively, if we got rid of all the expensive
operations -- including push, pop, shift, unshift and delete -- and just
left a raw buffer, then I'd be happy too, although I'd probably turn around
and want to build full-feature versions as well.)