On Tue, Jan 23, 2007 at 07:23:31PM -0800, Darren Duncan wrote:
: At 6:22 PM -0800 1/23/07, Larry Wall wrote:
: >Recently I started redefining C<map> to return multislices such that
: >
: > map { $_, $_ * 10 }, 1..3
: >
: >seems to return 1,10,2,20,3,30 by default, but in a multidimensional
: >context:
: >
: > @@multislice := map { $_, $_ * 10 }, 1..3
: >
: >it would have the value [1,10], [2,20], [3,30].
:
: Maybe I'm missing something important that would affect various new
: Perl 6 features, but if not then we could simply do this like it is
: done in Perl 5, which is to use the "smooth" approach all the time,
: and if people want chunks, they do something that would cause
: explicit chunking.
Perl 5 has lots of places where it doesn't scale to a multi-programmer
team very well. Arguably the assumption that you have control over
the entire source code is one of those places.
: Eg, smooth:
:
: map { $_, $_ * 10 }, 1..3
:
: Vs chunky:
:
: map { [$_, $_ * 10] }, 1..3
You seem to have picked the one function where that approach is possible. :)
(Well, arguably C<take> could use that approach too if you have control
of the code doing the gathering. But what about things like C<split>
and C<zip>?)
But the point is *not* to force it one way or the other--the point is
that many such functions would probably prefer not to commit one way or
the other, and they can't do that if they automatically throw away the
"dimensional" information. Looking at it from the other end, you may
not have control of the code that is returning the multislice. If the
code predecides for you, then either you have to explicitly strip away
the top level of [] all the time, or you can't even reproduce the []
structure because the run-length information is discarded. That's why
I think the default should be to hide the top-level [] in what we call
a multislice, and give the user the choice of whether to unflatten it
or leave it (seemingly) flat to begin with.
Larry
