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

Close. The argument is more like:
One has a reasonable expectation of seeing a list following a paren when declaring and initializing a hash or array (%hash= and @array=), so parens indicate the presence of a list.
My thought was to connect the idea of passing in a list of key/value pairs to the parens. So if someone is not sure which one to use they could think "[]=array, {}=hash, and ()=list, and I'm assigning it a list of key/value pairs, so I guess I should use parens". Not perfect, but I really didn't see how just thinking of them as precedence overriders would aid in dispelling confusion over when to use () instead of {} or []. But associating the parens with lists -- something similar in concept to arrays and hashes -- would help. It's not a perfect answer, but one hurdle at a time.

Update: 89% was just a high number. Could have been any example. Was not claiming it was accurate. Was just using a very high number as a tie-in to expectations. Trying to read any validity or claim of validity for that number completely missed the point.

Elda Taluta; Sarks Sark; Ark Arks

Replies are listed 'Best First'.
Re^34: Why? (each...)
by JavaFan (Canon) on May 20, 2011 at 23:48 UTC
    So if someone is not sure which one to use they could think "[]=array, {}=hash, and ()=list, and I'm assigning it a list of key/value pairs, so I guess I should use parens
    Yeah, except they will be thinking, "ah, I'm assigning to an array, so I must use []". It's a really bad meme, because all three are actually wrong. [] doesn't create arrays, it creates (in the right context) references. Same with {}.
[reply]
[d/l]
[select]
      Don't be so literal, it's just a loose association to tie the three together. And I wouldn't call it a bad meme -- more like a mental trick or reminder to help get past a mental block. Sometimes it's more important to forge ahead and then circle back. Once he starts getting the assignments right things should start to become clearer, and he'll be ready to circle back and clear up any remaining misunderstandings. That's my take on it. That's based on my college experience where I had C before Assembler. Pointers were so confusing in C, but then they made sense in Assembler. Not a problem since then. And and as a side note, having C first may have made it easier to pick up on assembler (a lot of things "clicked"). Anyway, the Op can stay confused about () vs. {} in %hash= context, or he can get past that, and then later on learn that the parens are not so directly tied to lists after all. No offense, but the "(LIST)" pseudo-idiom does a pretty good job of getting people to a level where they can grasp what's really going on.

      Elda Taluta; Sarks Sark; Ark Arks
[reply]
        ... the "(LIST)" pseudo-idiom does a pretty good job of getting people to a level where they can grasp what's really going on.

        I find that explaining to people what's really going on from the start—rather than pretending that context is some strange and scary thing that you only learn after a decade of experience—is rather easy. After all, anyone whose native spoken language has subject-verb number agreement already understands it.

        The notion that parentheses create some sort of first-class data structure known as a list is nonsensical in Perl, and it leads to strange misunderstandings and false cognates between other languages. Far better to avoid that mess altogether when the alternative is so much easier (and so much more accurate).

[reply]

        And I wouldn't call it a bad meme

        Unfortunately, even after being shown that it is.

        more like a mental trick or reminder to help get past a mental block.

        [] (array ref) vs {} (hash ref) vs neither (array or hash) is far more accurate, and it's just as simple.

        Once he starts getting the assignments right things should start to become clearer

        Except that getting the assignments right is the context. It's rather useless to teach him something that he'll only understand once he learns it by some other means.

        Anyway, the Op can stay confused about () vs. {} in %hash= context,

        You're saying people don't need to know everything right out the door. That's true, but it doesn't apply here. The truth is actually simpler that the confusing misinformation he was given.

[reply]
[d/l]
[select]
Re^34: Why? (each...)
by ikegami (Patriarch) on May 21, 2011 at 00:40 UTC

    Same rebuttal.

    Even with your made up number of 89%, that means one bug every 10 parens when declaring and initializing a hash or array. That's a huge error rate! Much too great to use in teaching.

    Was not claiming it was accurate.

    Yet your whole argument depends on it.

    So if someone is not sure which one to use they could think "[]=array, {}=hash, and ()=list, and I'm assigning it a list of key/value pairs, so I guess I should use parens".

    (I'm going to assume you meant "array ref" and "hash ref". Clearly one shouldn't use @a = [1,2,3]; to create an array with three elements.)

    This is a false trichotomy. [] (array ref) vs {} (hash ref) vs neither (array or hash) is far more accurate. This is what I told the OP.

[reply]
[d/l]
[select]
[reply]

In Section Seekers of Perl Wisdom