* Reini Urban <rurban@x-ray.at> [2012-06-25T19:43:09] > Do you really want Perl to compile invalid syntax starting with 5.17 > just because your code generator sucks? It's not invalid syntax forever just because it was once. It seems open to change. The question is: what's the cost, and what's the benefit? The cost at the language level seems minimal. It does not allow something semantically absurd, just pointless. Pointless is okay, if it makes things simpler under the hood: perl -e '();;;()=((),,,,())=();;;()' The benefit at the language level is very small. It means that when we say "list," we more often consistently mean "empty is okay, too." It's still not great, because we need the parens for the empty list but not a one-element list. But that's close to some other uses. So it brings things just a little closer to consistency. So, at the language level, I don't think these changes are too compelling either way. I wouldn't see much reason to pick either keeping or changing things, based on that. (If nothing else, the error message can definitely be improved.) What about the implementation? Does it make the life of the implementation easier to allow C<my ();> ? > >> >> Why should "my ();" parse correctly? > >> >> Why should "my;" parse correctly? Both are clearly syntax errors. > > > > "my ()" should parse correctly because you'd have to introduce a > > special case to disallow it. (I'm talking about Perl here, not perl. I > > don't care much about how it's implemented.) > > I did not disallow it, I changed the error message. It was someone else > who brought the parser up to MAD inconsistency instead of changing > the error message and fixing MAD. He isn't saying that *you* disallowed it. He means that in the simplest form of expressing my's definition, "my ();" would accept an empty list, and more work would be needed for one to expressly disallow it. To avoid unnecessarily adding more rules, he says it should be allowed. (Occam's Razor) -- rjbsThread Previous | Thread Next