in reply to Re^20: Why? (each...)
in thread Why? (each...)

I understand. I think Re^11: Why? (each...) comes closest to what I was trying to convey. There's a reason we use syntax like "my %hash = ( x=>1, y=>2, z=>3)" and I was trying to make the point that the reason is passing in a list of key/value pairs (well, it's the most common reason/use/syntax). Or to put it differently, how does mentioning using parens to override precedence help the OP? It's analogous to pasting the source code in. I tried to present a simplified answer that I thought would help the OP in the specific situation that came up in the original question. My question to ikegami about the parens indicating a list was, as I mentioned, in that same context. The purely technical answer is they override precedence. But we do that so we can assign a list of key/value pairs to the hash. And it's that reason that is important. The OP was confused about when to use {} and (), not when to use the comma operator. To reiterate, I went with a less technical but hopefully more useful answer (to the OP). As a side note, in the context being discussed the parens do indicate a list.

Elda Taluta; Sarks Sark; Ark Arks

Replies are listed 'Best First'.
Re^22: Why? (each...)
by ikegami (Patriarch) on May 17, 2011 at 23:30 UTC

    I tried to present a simplified answer that I thought would help the OP in the specific situation that came up in the original question.

    Perhaps, but the answer you did present was actually harmful.

    Perhaps you meant to say that "parens are needed around the list"?

    Or to put it differently, how does mentioning using parens to override precedence help the OP?

    If you want to open discussions as to how to improve my answer, by all means do so.

    But we do that so we can assign a list of key/value pairs to the hash.

    Not true at all. Parens are only used in assigning lists of key/value pairs to hashes in a small percentage of situations.

    As a side note, in the context being discussed the parens do indicate a list.

    Just like my car doesn't indicate a road, those parens don't indicate a list.

    Take away the parens, and the list is still there. Replace the list with something else, and you don't have to remove the parens. The parens are in no way related to any list, so they can't possibly indicate a list in «my %hash = ( x=>1, y=>2, z=>3 );».

[reply]
[d/l]
[select]

      ikegami,

      Actually, at a certain level of granularity, your car does indicate a road. At least more so than it would indicate a peanut-butter-and-jelly sandwich. And I think that is what Argel is getting at. He is simply suggesting to novice users to memorize the (LIST) idiom when initializing a hash or array and forget about understanding why for now. In his effort to do this, he writes a simplism but that seem not so harmful.

      Argel,

      On the other hand, this is sundialsvc4 asking this, and from what I've seen of his posts, he's more than ready enough to comprehend the full truth: that the parenthesis are just there for operator precedence so the comma expressions get evaluated before the assignment.

      In fact, I also used to trip up now and again while initializing an array or hash and use {} or [] instead of (), but thanks to ikegami's presumably good-intentioned opaqueness, I actually paused and thought about why parentheses, and thus it will never be an issue again for me as I finally understand.

[reply]

        Actually, at a certain level of granularity, your car does indicate a road.

        Really? Which road does it indicate? I bet you want to answer "the one it's driving on", but it's neither driving nor on a road. So again, which road does it indicate?

        He is simply suggesting to novice users to memorize the (LIST) idiom when initializing a hash or array and forget about understanding why for now.

        As he said, that is what he tried to suggest. "Use (LIST) to initialise a hash or array" is vastly different than "Parens indicate a list."

        The former is explains one method of initialising a hash. The latter is incorrect and doesn't even help in the specific situation it's suppose to help.

[reply]
      Interesting how we seem to have never been on the same page on this and probably never will be. As an example:
      But we do that so we can assign a list of key/value pairs to the hash.
      Not true at all. Parens are only used in assigning lists of key/value pairs to hashes in a small percentage of situations.
      Yet that is precisely where the OP made his mistake and thus the actual context I have been discussing this in (and the same situation for arrays)!! Which I have explained before. If we are not on the same page and apparently never will be, then there's no point in continuing.

      Elda Taluta; Sarks Sark; Ark Arks
[reply]

        You've said two contradictory things repeatedly. That the context is my %hash = ( a => 1, b => 2 );, and that it's about the mistake the OP made. Either one I address, you say the other is the context.

        Both have been addressed.

        It's been shown why parens don't indicate it's a list in my %hash = ( a => 1, b => 2 );.

        It's been shown that saying that parens indicate a list doesn't help initialise a hash correctly.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom