Odd behaviour of ResizableWhateverArray PMC's

[Andrew Whitworth]

I've heard a pretty sizable number of complaints recently regarding
the various *Array types, their behaviors and their implementations. I
think it may be worthwhile for us to start thinking about what
behaviors, exactly, these types are intended to provide. It would also
be a very good idea to standardize syntax and semantics between these
types so they tend to act similarly.

I've started a tasklist page on the wiki where we can list the kinds
of Array types we want to have, what their purposes and behaviors
should be, and what kind of work is needed to get them there.

https://trac.parrot.org/parrot/wiki/ArrayTasklist

--Andrew Whitworth



On Fri, Oct 9, 2009 at 1:45 AM, Martin Kealey <martin at kurahaupo.gen.nz> wrote:
>
> 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.)
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>