Re: RFC 203 (v1) Arrays: Notation for declaring and creating arrays

<Removed RFC announce list x-posting>

[email protected] wrote:
> Perl6 RFC Librarian wrote:
>
> > The bounds of an array or list can be specified at run time, of course:
> >
> >   my int @t1 :bounds(@dimList) = getFromSomeplace();
>
> Hm, I think some clarification would be good. I'd imagine three cases:
> (1) getFromSomeplace returns an untyped and unbounded LOL. In that case
> I'd write
>
>    my int @t1 : bounds = getFromSomeplace();
>
> and the bounds should be automatically figured out from the returned
> LOL.
Let's split the :bounds issue from the typing issue.

:bounds is never required. A list (of lists...) is an array if the list is
of a simple type (all quotes here from RFC 203):

<quote>
It is proposed that if a list is declared that specifies a simple type for
its elements:

  my int @a;

then that list be stored as an array--that is, contiguously in memory
</quote>

The only role of :bounds is that:

<quote>
a new C<:bounds> attribute:

  my @a :bounds(3);

that defines the maximum index for a list
</quote>

So,

  my int @t1 = getFromSomeplace();

does not need :bounds to become a true array. Adding :bounds does two
things:

 1- Adds range checking (since exceptions are defined for access outside the
range)
 2- Allows the block of memory to be preallocated

(2) can also be achieved by simply setting the bottom right element to
undef, or by setting @#array. The behaviour of (1) removes autovivification
of new elements, since an exception is raised instead.

> (2) getFromSomeplace returns already a typed bounded array:
>
>    my @t1 = getFromSomeplace();
>
That is already covered in the RFC ('Where the type and bounds of an array
can be derived at run time, it is not necessary to specify them
explicitly').

> or (3) getFromSomeplace returns a normal perl list or LOL and I want it
> to be reshaped (according to @dimList with clipping?) into my new bound
> array:
>
>    my int @t1 :bounds(@dimList) = getFromSomeplace();
>
:bounds doesn't reshape. If the returned array overshoots specified :bounds,
an exception is raised. Reshaping is done with reshape() (RFC 148),
merge()/demerge() (RFC 90), and part()/flatten() (RFC 91). I don't like the
current reshape() semantics, and have asked Nate (the author of RFC 148) to
change them to match Numeric Python's reshape()

  http://starship.python.net/~da/numtut/array.html#SEC4

(search for 'reshape'). I have heard back a yay or nay yet on this.

Specifying the type does, on the other hand, turn a Perl 5 style LOL into a
true array, if the type is a simple type. What is a simple type? ...I'm not
sure--it would sure be nice to specify the properties of a simple type so
that we can add additional ones beyond those builtin. Suggestions here most
welcome...
> >
> > Where the type and bounds of an array can be derived at run time, it is
> > not necessary to specify them explicitly:
> >
> >   my int @t1 :bounds(@dimList) = getFromSomeplace();
> >   my int @t2 :bounds(@dimList) = getFromSomeplaceElse();
> >   my @prod = @t1 * @t2;   # @prod magically has type (int) and :bounds
(@dimlist)
>
> What happens when pairing typed/untyped bounded/unbounded arrays in such
> operations. The stricter one wins? I'd imagine the usual type
> conversions happen automatically. Should there be an RFC detailing the
> data types and conversions that one would want, e.g. a complex type,
> etc?
>
I would have thought the looser type wins, and untyped would win over typed.
Therefore int*double = double, and int*<untyped> = <untyped>.

Any unbounded array in an operation would make the result unbounded.

> > and its bounds can be locked in as well if required:
> >
> >   my @some_LOL = ([1,2],
> >                   [3,4]);
> >   my int @array :bounds(@#some_LOL) = @some_LOL;
> >
>
> Again, couldn't we just imply the bounding, i.e.
>
>     my int @array :bounds = @rvalue;
>
> always meaning
>
>     my int @array :bounds(@#rvalue) = @rvalue;
>
We could make :bounds' parameter default to the current dimensions of the
array. Yes, I'll add that in.

Thanks for the thoughtful critique, Christian.