Juerd writes:
> What if instead of
>
> my @copy = @array;
> while (my @chunk = splice @copy, 0, $chunksize) {
> ...
> } # ^1
Well, I for one never write that. I very seldom use splice.
>
> we could just write
>
> for @array [/] $chunksize -> @chunk { ... }
Well, we could also write:
for @array -> $a, $b, $c {...}
But if we're dealing with the chunks, rather than named pieces of the
chunks, then I wonder if this would DTRT:
for @array -> [EMAIL PROTECTED] is shape($chunksize) {...}
I have difficulty believing that that would work. Essentially we need a
way of saying that the arity of a parameter list is a specific size, but
that we want to put all the arguments into an array. And of course if
it were possible, then the above would be the way to do it.
Your "list mod" idea is interesting, though. I fear that adding too
many list operators will start to make us look like Haskell, where we
have *extremely* expressive single lines that take an hour to write and
an hour to read (I call this "concise hell"). I think the fact that we
have other WTDIs might save us from that, though[1].
I remember talking to an APL programmer at the last OSCON, who believed
that APL captured a program's essence. The fact that you could do very
complex things using combinatorial meta operators in very few characters
seemed to him to define the true nature of programming (Identifying
programming much more with mathematics than with engineering on this
front). It is questionable whether we should give him his essence in
Perl 6. On one hand, it's another paradigm, and Perl 6 is
multiparadigmatic so that everybody feels comfortable writing it. On
the other hand, the more paradigms we include, the more code readers
won't understand (and learning new paradigms is very much harder than
learning new syntax).
Still, Perl's module theory of encapsulation works somewhat well for a
multiparadigmatic language, where generally only one person has to
understand the code... but he has to understand it very well.
But I digress (one wonders how *that* came out of this proposal).
[1] Keep in mind that I don't necessarily consider concise hell to be a
bad thing. I just consider it very different from the direction Our
Successful Perl has gone so far, and certainly different from the way I
like to write/read code. But I'll use concise hell as a negative
connotation for the rest of this email, because I'm subjective like
that.
> and instead of
>
> my $copy = $string;
> while (defined(my $chunk = substr $copy, 0, $chunksize)) {
> ...
> } # ^2
Which is very rare in the regexy world of Perl. I almost never use
C<substr>, since regexes do everything I ever wanted to do with strings
but was afraid to ask.
> we could use
>
> for $string ~/ $chunksize -> $chunk { ... }
>
> I think it'd make life much easier.
Supposing that we see a need for an operator like this.
I wonder if we're diving so far into the realm of consistency with this
proposal that it would be better to talk about the ~ and [ ]
metaoperators. And of course the + variants of these operators could
not exist since numbers behave quite differently from sequences.
So, let's consider for a moment what a string looks like if it were just
like a list of characters (barring Unicode discussions which I generally
try to avoid). Let's use ~[] for string-meta and *[] for list-meta.
~[~] is just like ~, but *[~] concats two lists, an operation perl
has seemed lacking (not that that's been an issue).
*[<<] is shift, *[>>] is pop, ~[>>] is chop, ~[<<] is that other one
that people have requested.
I don't know what the meta-comparison operators would do. If we
define them so that: [$a, $b, $c] *[<] [$d, $e, $f] === $a < $d &&
$b < $e && $c < $f, then we find that *[<] and *[>] are mostly
adding syntax for something relatively uncommon that deserves a
name (and is starting to look like concise hell). *[==] on the
other hand is extremely useful, and is something that perl has
lacked in its core for ages.
Uh, that's about all I can really think of for useful operators.
Perhaps I'm missing some (like your modulus, but that's defining a new
sequence mod operator anyway). All in all, I don't think meta operators
buy us very much in this case, except for more tickets to concise hell.
Perhaps a good thing to do here is to separate out a class of "sequence"
operators, like ~ and your [/], define them parallel-like for
strings and lists, and see how that looks. If I were the one doing
this, I would try to keep the list of sequence operators small (not
every operator need have a sequential analog).
Luke
