--- Luke Palmer <[EMAIL PROTECTED]> wrote:
[[... Massive elision ...]]
> I'm thinking it would be a very good idea to unify C<for> and C<map>
> in their argument style. I still think the distinction between
> C<for>'s void and C<map>'s list context is a good one; i.e. don't
> make them I<entire> synonyms.
>
> But it seems natural to have C<for> a method of C<Array>, however
> unnatural that seems. I don't know, my thoughts are quite unclear at
> this point; perhaps I'll write back when I've thought about this a
> bit more.
On a somewhat disjunctive note, if you're going to play games with
unifying C<for> and C<map>, let's undef the operation-order of map.
That is,
for (1,2,3) { print }
# 1 2 3
map { print } (1, 2, 3) # or however you rewrite the syntax
# ? ? ?
@a = map { print } (1, 2, 3)
for @a { print }
# 1 2 3
Note that the order of the results of map would still be guaranteed,
but not the order of operation. This is for threading, obviously, and
we should probably do the same thing everywhere we can, so that if you
want serial operation, you use "for" or some construction that honors
ordering attributes internal to the data.
The point is to warn people that preserving state in map blocks won't
work, although stateless data or statistics will:
map { count++; ... } @array # works fine -- count == array.length
map { %hist{$_}++ } @array # works fine -- hist{} counts occurrences
map { ...$last ...; # I do not think that code
last=$_; ... } @array # means what you think it means...
=Austin
