Ken Fox wrote:
> Sometimes array references behave as arrays, e.g.
>
> push $array, 1
>
> In flattening context array refs don't flatten, only arrays.
> I'm not even sure that only arrays flatten either -- it might
> be anything that begins with @. e.g.
>
> my Point @p;
> ($x, $y) := @p;
>
> If the flattening rule is "only @ symbols flatten" then it
> would be lexical flattening -- we only have to look at the
> text. (I'm using lexical in the same sense as lexical
> variable uses it.)
That would certainly make sense.
> It would actually be nice if all the C<push>, C<pop>,
> etc. functions became methods, e.g.
>
> push @array: 1;
I'm undecided on that. I can certainly see the appeal though.
>> Depends on your definition of simpler, I guess.
>
> I don't see anything particularly complex about this:
>
> my $index = 0;
> for @classifiers {
> return $index if $_.($nextval);
> ++$index
> }
Apart from the fact that it creates a gratuitous lexical outside
the scope of the C<for> block. And that it requires explicit vs
implicit incrementing of the index variable. And it won't work if
the array doesn't start at index 0, or doesn't have contiguous
indices.
Whereas:
for @classifiers.kv -> $index, $_ {
return $index if $_.($nextval);
}
suffers from none of those problems. And has half as many lines.
And encourages the coder to name the topic something more maintainable:
for @classifiers.kv -> $index, &classifier {
return $index if classifier($nextval);
}
> That's understandable and it should produce simple bytecode.
We're probably not going to convince each other.
I guess it's a religious issue. ;-)
> Yes, I agree, but it needs to construct a stream generator
> which isn't particularly efficient.
I suspect that .kv iterators will be *very* lightweight.
Precisely because they will be heavily used for this very idiom.
> I was surprised to see it
> in a place where the generality and elegance isn't needed.
IMHO there is *no* such place. ;-)
> Thanks for the explanation of the junction. I'm not sure
> whether I'm more excited by the possibility to write code
> using junctions or more terrified by the certainty of
> debugging that code... ;)
Well, I'd hope you'd be *both*!
> How about formalizing global namespace pollution with something
> like the Usenet news group formation process? Ship Perl 6 with a
> very small number of global symbols and let it grow naturally.
I'm not in favour of that. Most of the things we're having to
fix in Perl 6 are things that "grew naturally" in Perl 5.
Evolution is *greatly* overrated.
Damian
