You want a zip:
my %h = @k ¥ @v;
my %h = @k Y @v; # ASCII fallback
my %h = zip(@k, @v); # or maybe zip(@k; @v) this week?
--
Gaal Yahas <ga...@forum2.org>
http://gaal.livejournal.com/
I could use a direct translation of the P5 idiom:
my %h;
%h{@k} = @v;
But is there an easy way in Perl6 to do it all in one go? Should this work?
my %h = @k [=>] @v;
--
Mark J. Reed <mark...@mail.com>
Reduce operators only turn infix into list operators. What you really
want here is a hyper-fatarrow:
my %h = @k »=>« @v;
Larry
Hyper is not [], but >><<. And >>=><< works perfectly in Pugs, and does
exactly what you describe.
[] is for reduction, and is prefix: [+] 1,2,3
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Gaal pointed out using zip. What would be the difference then between a
hyper-fatarrow and zip in this case?
Michael
That would have worked back when zip merely interleaved, but now it makes
sublists, and so we would have to teach hash assignment to transform [$k, $v]
into ($k,$v) or $k=>$v. Might not be a bad idea.
: my %h = zip(@k, @v); # or maybe zip(@k; @v) this week?
It would be zip(@k;@v). zip(@k,@v) would only have one dimension, so
would just concatenate the two lists and put each element into its
own sublist.
Alternately, for the old zip semantics we have each(@k;@v), which
makes a list with interleaved keys and values. It's just there's no
operator like ¥ for it (yet).
But I'd still probably use a hyper-fatarrow for this case rather than
relying on interleaving.
Larry
Ah, right. Silly me. I got hyper and reduce confused. Thanks!
Gaal pointed out using zip. What would be the difference then between a
> hyper-fatarrow and zip in this case?
Effectively none. But I think the hyper-notation is clearer here. Both ¥
and => make pairs, but at least to me, => conveys more explicitly that it's
not just any old pair but specifically a key/value pair. (Even though =>
also creates Pairs of the "any old" kind.)
Another reason for preferring hyper is that it makes promises about
parallelizability, whereas the zip/each solutions would tend to
assume the input streams must be processed in order, albeit lazily.
(Probably doesn't make much difference until someone actually attempts
to vectorize Perl though, and even when that happens, it's not clear
what the exact sequence of events would be if you feed a lazy pipe
to a hyper...)
Larry