For me, this space-matters-in-some-situations thing is probably the one I dislike the most in Perl 6.
Isn't it the other way around?
Currently, space-matters-in-some-situations in Perl 5; and this is the antidote to it. No space allowed between a function name and it opening paren. Sorted.
(Is it any different to requiring that there be no space between '=' & '~' in the regex operator?)
It's correcting a problem (in Perl5) rather than creating a new one.
'cept maybe for those who dogmatically believe that the close presence of a ( makes this: func (); suddenly become invisible: func( );. I can still see it.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
| [reply]
[d/l]
[select] |
I know that I am going to bump into it, over and over.
I don't experience it that way personally. (I've started using Perl 6 for some of my private scripting needs a few months ago, which doesn't give me a huge amount of experience with it, but at least a general feeling for the language.)
Once you internalize the rule that the paren has to immediately follow the identifier, you start looking at them differently – almost like they form a single token. And you really only need to think about it when writing a new function call, which is exactly when your brain is most likely to remind you of the syntax rules for function calls... ;)
OTOH the Perl 5 ambiguity that I demonstrated by example in my above answer, is something that I still run into every now and then even after many years of using Perl. Because at the time when you add the parens in such a situation, you're probably not thinking about function calls, but rather about the Perl features involved in extending the expression you're editing: in the example of extending $line to (" " x $n).$line, that would be the repetition operator and string concatenation.
It takes discipline to consciously pay attention to the fact that the expression which you're editing there is actually the first argument to a listop, and thus requires special care with parens – and if you're a human programmer, you're bound to sometimes overlook such things, resulting in a compiler warning in the best case, and an unnoticed bug in the worst.
That's my experience, at least... Other people's brains may work differently. :)
| [reply]
[d/l]
[select] |
