in reply to Re (tilly) 3: Declaring and initializing a hash with a list of keys and a list of values
in thread Declaring and initializing a hash with a list of keys and a list of values

But then there must be a block for my. But the expression behind for could be arbitrarily complicated and must be evaluated in a wider context. Then there is an equivalency to map to maintain. 
map {@$_{@keys}=@values}\my%hash;

[download]
and when were functionarguments a block?
  • Comment on Re: Re (tilly) 3: Declaring and initializing a hash with a list of keys and a list of values
  • Download Code

Replies are listed 'Best First'.
Re (tilly) 5: Declaring and initializing a hash with a list of keys and a list of values
by tilly (Archbishop) on May 15, 2001 at 23:27 UTC
    As danger's output demonstrates, Perl does a horrible job of parsing this. It could be asked why it matters more that: 
    A for B;

    [download]
    should similar scoping effects to: 
    map {A} B;

    [download]
    when good Perl programmers discourage the former, and the principle of least surprise would lead many to expect it to behave like: 
    for (A) {B}

    [download]
    which is - judging from the Deparse output that danger posted - darned close to what Perl does anyways. Besides which, the things you claim are equivalent are not. Compare: 
    my $foo for ();
map {my $foo} ();

    [download]
    The scope of $foo is different in the two cases for unsurprising reasons. (The infamous my $foo if 0; problem of persistent lexicals also shows up...)

    But anyways this is a boundary case in the logic which I could see changing by accident fairly easily. It wouldn't be the first scoping rule involving a loop that was the subject of a Perl bug. Which doesn't count the fact that Perl has in the past altered in subtle ways the scoping rules around lexicals and loops. So this code is something I don't really feel comfortable with.

    At this point I can see you shaking your head. But as merlyn admitted, with 6.0 all bets are off. I would have zero confidence that this scoping issue is not something that is in danger of going wrong in 6.0's automatic 5.x conversion facility. Don't believe me? Well there is one tool on a similar principle which the perl folks built already - and danger already showed that it messed up...

[reply]
[d/l]
[select]
      Huh? *I* would expect A for B similar to for(B){A}, and not  for (A) {B}. Your second example shows the my in the loop, where a block semantic can be simply defined. That this *possible* block semantic is not defined and your map-Example suffers only from the explicitly defined (see the curlys) block is a not so surprising *equivalence*. The only difference is in the eye of the beholder.
[reply]
[d/l]
[select]
        I don't know why you are being so hostile, but I see little point in continuing.

        Yes, I had a thinko and switched A and B once. BFD. As for the rest run the following code and observe the scoping carefully: 

        for (my $foo) {
  $_ = "In scope";
  print "Inside: $foo\n";
}
print "Outside: $foo\n";

        [download]
        If you can get Perl 5.003 and run the same code. Note the differences.

        This change is no larger than it would be to see the inline for loop scoped exactly like a regular for loop. That change would ruin merlyn's snippet. Therefore, knowing about this past change, I raised my concern over whether this specific scoping detail was likely to be safe across releases of Perl. merlyn said point blank that it was a risk, but thought it didn't matter much since so much will change in Perl 6.

        I don't think I have any more to say on this topic. You wanted to know why I asked the question. You have your answer. No matter how stupid you think the question was, both merlyn and danger gave me reason to think that it was not unreasonable...

[reply]
[d/l]

In Section Cool Uses for Perl