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

I think you're argument is:

One has a reasonable expectation of seeing a list following a paren, so parens indicate the presence of a list.

I stipulate that this is a valid argument — true if it's premises are true — but I don't buy the premise.

The odds of seeing something other than a list after a paren is too great for it to be reasonable to expect to see a list following a paren.

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

Replies are listed 'Best First'.
Re^33: Why? (each...)
by Argel (Prior) on May 20, 2011 at 23:25 UTC
    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
[reply]
      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]

      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