Nick Sabalausky: >I find that example to count as a good argument against optional-semicolons.<
Yep, that example was optional semicolons as implemented in JavaScript. I agree that a bad implementation of this feature is worse than not having it. >Sure, there may be ways around it, but the rules involved would be >complicated, and also difficult to get just right.< If its rules are complicated, then in my opinion it's badly designed. See below. >AI do a lot of line-juggling, so I've always found explicit line continuation >operators to be a royal pain in the ass.< I have written a large amount of Python code, and I use a line continuation symbol probably every 50000 chars of code&comments, so for me it's not a pain. >From what I've seen in the Python newsgroups, this is not among the top >fifteen Python complains :-) ------------------ Jeff Nowakowski: >Scala's implicit semicolons aren't without problems. There have been several >posts on the issue. Here's an example: [...] >"As a scala newbie I find the implicit semi-colon rules in scala more a >hinderance than a help. Being a believer in the 80-column rule I find myself >often pondering "where can I break this line without the compiler thinking I'm >trying to imply a semi-colon?" This is not an easy question to answer for one >new to the language. Particularly when said language already has a complex >syntax due to diverse minimization rules."<< Ary Borenszweig: >On the other hand, I just made a small test and I think Python can be >improved. [...] As you can see, when python encounters an end of line after a >+ is chokes, gives an error. Ruby is smarter in that it knows that you intend >to add another operand, be it in the current line or in another line. That's >what I mean with understanding line endings in a smart way. The same goes in >ruby with many other things:< Thank you for your answers, and thank you for that note about Scala, it seems I was wrong, the Scala design here is not good enough. The juxtaposition of those two comments offers me a chance to explain things better. Design of a language can be anti-intuitive, and sometimes what looks better is worse. Python resists strongly to such "improvements", and will probably never "get better" in this regard. There are two rules of the Python Zen about this: * Special cases aren't special enough to break the rules. * In the face of ambiguity, refuse the temptation to guess. Python prefers to use only this to manage end of lines: the newline is the end of the line. The exception: if you have opened a parenthesis, the line continuation is implied until you close it. Here Python never guesses and it's dumb. It doesn't add semicolons as JavaScript, and and it never implies a semicolon as Scala. This makes this feature simpler to implement, simper to understand, and about this there are zero (or just one) questions to answer for newbies. As Sabalausky says it's not perfect, but perfect things are rigid and boring :-) I think this is an example where a smarter design is worse. Bye, bearophile
