in reply to Re: Re (tilly) 1: 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

The purpose of the loop is to initialize a hash that he wants to be available afterwards. If the scoping changes then he has initialized a private hash that disappears before he ever gets a chance to use it. Oops...

strict would catch this change.

  • Comment on Re (tilly) 3: Declaring and initializing a hash with a list of keys and a list of values

Replies are listed 'Best First'.
Re: Re (tilly) 3: Declaring and initializing a hash with a list of keys and a list of values
by Anonymous Monk on May 15, 2001 at 22:44 UTC
    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?
[reply]
[d/l]
      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]

In Section Cool Uses for Perl