develooper Front page | | Postings from September 2000

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

Thread Previous
Jeremy Howard
September 8, 2000 23:58
Re: RFC 203 (v1) Arrays: Notation for declaring and creating arrays
Message ID:
<Removed RFC announce list x-posting> 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):

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

The only role of :bounds is that:

a new C<:bounds> attribute:

  my @a :bounds(3);

that defines the maximum index for a list


  my int @t1 = getFromSomeplace();

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

 1- Adds range checking (since exceptions are defined for access outside the
 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

> 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()

(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
> >
> > 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
> 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.

Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About