Looks at 11 languages, ignores Haskell or anything really different...
or Raku
No Semicolons Needed
11–20 of 92 posts
Re: No Semicolons Needed
#12This article makes a strong case for every language to use ‘;’ as a statement separator.
Re: No Semicolons Needed
#13> I would love to see a language try to implement a rule where only an indented line is considered part of the previous expression.
After python, it seems like every language decided that making parsing depend on indents was a bad idea. A shame, because humans pretty much only go by indents. An example I've frequently run into is where I forget a closing curly brace. The error is reported at the end of the file, and gives me no advice on where to go looking for the typo. The location should be obvious, as it's at exactly the point where the indentation stops matching the braces. But the parser doesn't look at indents at all, so it can't tell me that.
Re: No Semicolons Needed
#14Can anyone give a good reason why supporting syntax like: y = 2 * x - 3 is worth it?
It's not. Your eyes can deceive you by guessing the correct indentation. Indentation should never be used for grammar separation. Explicit characters such as } ] ) are clearer and unambiguous.
Clearer for the computer, but not for the human. Many errors, some severe, have been caused by a human only looking at the indentation and not realizing the braces don't match.
Re: No Semicolons Needed
#15> how does Gleam determine that the expression continues on the second line?
The fact that it isn't obvious means the syntax is bad. Stuff this basic shouldn't be ambiguous.
> Go's lexer inserts a semicolon after the following tokens if they appear just before a newline ... [non-trivial list] ... Simple enough!
Again I beg to differ. Fundamentally it's just really difficult to make a rule that is actually simple, and lets you write code that you'd expect to work.
I think the author's indentation idea is fairly reasonable, though I think indentation sensitivity is pretty error-prone.
Re: No Semicolons Needed
#16Can anyone give a good reason why supporting syntax like: y = 2 * x - 3 is worth it?
Obviously, that's a really short expression.
So, the question is, if you have a long expression, should you have to worry too much about either adding parentheses, or making sure that your line break occurs inside a pair of parentheses.
It boils down to preference, but a language feature that supports whatever preference you have might be nice.
priority = "URGENT" if hours Re: No Semicolons Needed
#17> I would love to see a language try to implement a rule where only an indented line is considered part of the previous expression. After python, it seems like every language decided that making parsing depend on indents was a bad idea. A shame, because humans pretty much only go by indents. An example I've frequently run into is where I forget a closing curly brace. The error is reported at the end of the file, and…
Scala 3 decided to go with indents.
Re: No Semicolons Needed
#18> I would love to see a language try to implement a rule where only an indented line is considered part of the previous expression. After python, it seems like every language decided that making parsing depend on indents was a bad idea. A shame, because humans pretty much only go by indents. An example I've frequently run into is where I forget a closing curly brace. The error is reported at the end of the file, and…
I was much more opposed to this early on than I am now. With modern IDEs and extensions handling tabs vs spaces, tab width, and formatting, python ends up being very easy to read and write. I use it daily, and while I hate it for other reasons, I can't remember the last time I had any issues with indentation.
Re: No Semicolons Needed
#19Are we really saving that much by not having semicolons? IDEs could probably autocomplete this with high success, and it removes ambiguity from weird edge cases. On the other hand, I've not once had to think about where go is putting semicolons...
Re: No Semicolons Needed
#20Earlier quoted context omitted.
It's not. Your eyes can deceive you by guessing the correct indentation. Indentation should never be used for grammar separation. Explicit characters such as } ] ) are clearer and unambiguous.
Clearer for the computer, but not for the human. Many errors, some severe, have been caused by a human only looking at the indentation and not realizing the braces don't match.
> human only looking at the indentation and not realizing the braces don't match.
If it ever gets to that point, a refactor is obligatory.
Don't give the human tools to make easy mistakes. Any grammar can be abused, so blame the human for not writing clean code.