Wed, Aug 23, 2006 at 05:43:48PM -0400, Mark J. Reed wrote:
: Suppose I have two arrays @k and @v and I want to declare and initialize a
: hash %h such that %h.keys eqv @k and %h.values eqv @v.
:
: 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;

Reduce operators only turn infix into list operators. What you really
want here is a hyper-fatarrow:

my %h = @k => @v;

Larry

>
: 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;

Reduce operators only turn infix into list operators. What you really
want here is a hyper-fatarrow:

my %h = @k => @v;

Gaal pointed out using zip. What would be the difference then between a
hyper-fatarrow and zip in this case?

Michael

Thu, Aug 24, 2006 at 12:51:04AM +0300, Gaal Yahas wrote:
: Wed, Aug 23, 2006 at 05:43:48PM -0400, Mark J. Reed wrote:
: But is there an easy way in Perl6 to do it all in one go? Should this work?
:
: my %h = @k [=>] @v;
:
: You want a zip:
:
: my %h = @k @v;
: my %h = @k Y @v; # ASCII fallback

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

Wed, Aug 23, 2006 at 03:19:22PM -0700, Larry Wall wrote:
: But I'd still probably use a hyper-fatarrow for this case rather than
: relying on interleaving.

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