On Thu, Mar 29, 2007 at 01:21:27AM -0700, Darren Duncan wrote:
: At 7:28 PM -0700 3/28/07, [EMAIL PROTECTED] wrote:
: > =head1 Multidimensional arrays
: >
: >+Perl 6 arrays are not restricted to being one-dimensional (that's simply
: >+the default). To declare a multidimensional array, you specify it with a
: >+semicolon-separated list of dimension lengths:
: >+
: >+    my int @ints[4;2];          # Valid indices are 0..3 ; 0..1
: >+
: >+    my @calendar[12;31;24];     # Valid indices are 0..11 ; 0..30 ; 0..23
: >+
: >+You can pass a multislice for the shape as well:
: >+
: >+    @@shape = (4;2);
: >+    my int @ints[ [;[EMAIL PROTECTED] ];
: >+    my int @ints[@@shape];      # Same thing
: <snip>
: This is great and all, but ...
: How would one declare an anonymous multidimensional array value that 
: is compatible with this system?

Depends on what you mean by "compatible".  The semicolon notation is
really just intended for slicing subscripts, which are really just
two dimensional, so it's convenient to represent one of the dimensions
with semicolon rather than nested lists of some sort.

: Eg, with normal arrays, one can say [foo,bar,baz] to declare a normal 
: anonymous array value with those 3 elements.
: But say for example that one wants to do a matrix multiply of literal 
: values, and so each operand is a 2x3 array, and so is the result ... 
: could we do something like this:
:   my $result = [4,5;6,7;8,9] * [7,0;44,4;5,3];

Well, you want a hyperop there, but we might make that syntax work for
two dimensional arrays.  Semicolons don't conveniently extend to more
dimensions though without explicit bracketing.  But at any given level
we could replace [...],[...],[...] with ...;...;... as long as it's
unambiguous in context.

: Or that's probably bad syntax or example, but you get the idea; one 
: defined an entire multi-dim-array value inline and not with a bunch 
: of element assignments.
: I didn't see this matter addressed in Synopsis 9.

It could probably use some clarification.

: Or do you consider this unlikely, and that people who use 
: multidimensional arrays or hashes would be more likely to build their 
: values piecemeal, or use "arrays of arrays", which afaik are not the 
: same thing?

There are various ways to write multidimensional data; basically any
composite object potentially represents an item at object level but
a list of objects if asked to iterate somehow.  We've done a certain
amount of handwaving on multidimensional values, but my feeling is that
in a multidimensional context anything that can do Array or List can
be used as a sublist within a large list, much like we freely interconvert
strings and numbers where that makes sense.  So maybe it just doesn't
matter whether you write:

    my $result = [[4,5],[6,7],[8,9]] »*« [[7,0],[44,4],[5,3]];
    my $result = ((4,5),(6,7),(8,9)) »*« ((7,0),(44,4),(5,3));
    my $result = (Seq(4,5),\(6,7),[8,9]) »*« (\(7,0),[44,4],Seq(5,3));
    my $result = (4,5;6,7;8,9) »*« (7,0;44,4;5,3);

since potentially any flattening is done lazily, so if flattening
isn't wanted by the context, you don't get it.  But I freely admit
that I'm sorta waiting for the implementors to say what's practical
here, and I'd particularly like to see more participation from the
PDL crowd.  Unfortunately they're a rather practical set of people and
more interested in solving real problems than in painting linguistic
bikesheds.  'Course that's also precisely why I'd like to see more
of their input.  :-)

In any case, most of the syntax above is negotiable.  However,
literals defined with nested square brackets should work fine with
any data structure that they can be mapped to, whether declared as
a shaped array or as arrays of arrays.  The mapper just shoves any
early dimensions into the shape (if any), and the rest dangles off
each element as AoA (assuming the element type isn't forced to be a
simple type like Num there).  Offhand I don't see much problem with
this, but maybe it's just a big blind spot.


Reply via email to