Classic mistakes in language design that have to be fixed later.
- "We don't need any attributes", like "const" or "mut". This eventually gets retrofitted, as it was to C, but by then there is too much code without attributes in use. Defaulting to the less restrictive option gives trouble for decades.
- "We don't need a Boolean type". Just use integers. This tends to give trouble if the language has either implicit conversion or type inference. Also, people write "|" instead of "||", and it almost works. C and Python both retrofitted "bool". When the retrofit comes, you find that programs have "True", "true", and "TRUE", all user-defined.
Then there's the whole area around Null, Nil, nil, and Option. Does NULL == NULL? It doesn't in SQL.
That's what's nice about coarse-grained feature options like Rust's editions or Haskell's "languages", you can opt in to better default behavior and retain compatibility with libraries coded to older standards.
The "null vs null" problem is commonly described as a problem with the concept of "null" or optional values; I think of it as a problem with how the language represents "references", whether via pointers or some opaque higher-level concept. Hoare's billion-dollar mistake was disallowing references which are guaranteed to be non-null; i.e. ones that refer to a value which exists.
That's because SQL null is semantically different. Most nulls are a concrete value (null pointer). SQL null is the relational null ("not known"). It's closer to NaN (but still different)
The use of 'const' in C is very much a mixed blessing; I certainly have experience of the 'const poisoning' issue. Possibly it would have been better as a storage class.
For bool, yes it was a useful addition. Especially for the cases where old code would have something like:
> 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.
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.
I must disagree but only a tiny bit. modern IDEs try to indent and attempt to add indentation as you code which can cause problems sometimes.
tabs vs spaces is very painful still when copying code that is in a different format. it's not just tabs and spaces, but the width of the tabs and the spaces. Even with VSCode extensions and sublime text extensions I've struggled a lot recently with this.
I commented on a sibling thread just now, but it is still very easy in python to mess up one level of indentation. When I caught bugs of that sort, it was introduced either when copy pasting, when trying to make a linter happy and doing cosmetic cleanup, or when moving code around levels of indentation, like introducing a try/except. I had one recently where if I recall correctly I moved a continue statement under or out of a try/except when messing around with the try/except logic. it was perfectly valid, and didn't stand out much visually, pydnatic and other checkers didn't catch it either. It could have happened with a '}' but it's easier to mess up a level of indentation than it is to put the '}' at the wrong level. a cosmetic fix results in a logic bug because of indentations in python. with curly's, a misplacement of that sort can't happen because of indentation or cosmetic/readability fixes.
what the curly approach asserts is a separation of readability and logic syntax.
The interpreter/compiler should understand your code first and foremost, indenting code should be done, and should be enforced, but automatically by the compiler/interpreter. Python could have used curly braces and semi-colons, and force-indented your code every time it ran it to make it more readable for humans.
we don't even use indents that way in natural language. We use things like bullet points, we need specific markers.
space is for spacing, tabs are for tabulation, they are not in any human language I know of used as terminators of statements. You know what is the equivalent of an indent or a semicolon in english? a period. <-
We have paragraph breaks just like this to delimit blocks of english statements.
A semi-colon is used to indicate part of a sentence is done, yet there is still related continuation of the statement that is yet to be finished. Periods are confusing because they're used in decimal points and other language syntax, so a semi-colon seems like a good fit.
If I had my pick, I would use a colon to indicate the end of a statement, and a double colon '::' to indicate the end of a block.
func main(): int i - 0: do: i=i+1: print(i): while(i<10):: ::
another downside of indentation is it's award to do one-liners with such languages, as with python.
There is a lot of subjectivity with syntax, but python code for example with indents is not easy for humans to read, or for syntax validators to validate. it is very easy for example to intend a statement inside a for loop or an if/else block in python (nor not-intend it), and when pasting around code you accidentally indent one level off without meaning to. if you know to look for it, you'll catch it, but it's very easy to miss, since the mis-indented statement is valid and sensible on its own, nothing will flag it as unusual.
In my opinion, while the spirit behind indentation is excellent, the right execution is in the style of 'go fmt' with Go, where indenting your code for you after it has been properly parsed by the compiler/interpreter is the norm.
I would even say the first thing a compiler as well as interpreter do should be to auto-indent, and line-wrap your code. that should be part of the language standard. If the compiler can't indent your code without messing up logic or without making it unreadable, then either your code or the language design has flaw.
with apples in that list for example, you used '2.1' to indicate a new item, the space is cosmetic, the functional indicator is '2.1'
This wouldn't look right:
Introduction
Fruit
Apples
Red apples
Green apples
I'm sure you can work it out, but it doesn't feel natural, or ideal. (i can't get hn to format it without making it all one line so i used double new line).
it would look better still with a dash or a bullet point for every sub-entry. We're not arguing that it is possible to do that, we're arguing what is ideal for readability.
In that list you can naturally guess what that ordering is, but if the items were not so interrelated it can be confusing. if the top level item is 'Ham' and the indented item under it is 'sandwich' are you wrapping the same phrase 'Ham Sandwich' , because indentation (even in python) is used when wrapping lines, or is sandwich under ham as one of the things done with ham. it is thus error-prone and more confusing, clear and specific punctuation alongside indentation makes it easier to read.
No one is saying that indentation can not be used to display lists/sublists, I'm saying that markers remove ambiguity even across movement of blocks of texts.
What language is this? In C I get the correct position of the error because GCC also monitors the indentation as it parses.
A linter can point out errors based on indentation, and they frequently do. There's no need for the language to do it and then band-aid additional fixes for problems caused by significant white space.
rustc does exactly that keeping the indent level of every unbalanced curly brace. It works OK, but it isn't perfect by any stretch. More heuristics are needed.
> 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.
That's somewhat a quality of service issue though. Compilers should look at where the braces go out of kilter vs indentation and suggest the possible unmatched opening brace.
As a casual observer who has written perhaps a dozen lines of Scala in his life, I feel like Scala approaches any “pick one” decision with “why not both?”.
Kind of. It supports an end operator as well, and imo everyone should be using it. I actually really like the `end name` approach as opposed to the Lua-style plain ends.
The issue is that you find you very often want to break those roles. Python basically has `elif` because `else if` would make each branch nest one level deeper which isn't what one wants, except Python uses exceptions for flow control so you find yourself having to use `except ... try` as an analogue to `else if` but not `excetry` exists to do the same and stop the indentation.
There are many other examples. It exists to give people freedom. Also, while humans only go by intendation it's very hand for text editing and manipulation without requiring special per-language support to move the cursor say to the nearest closing brace and so forth.
The issue is that it's a special case that acknowledges where there are cases where the indentation level it logically requires isn't what programmers find pleasant, there are many more, that just don't have that special case, so it forces indentation that's unpleasant and unintuitive.
Perhaps having unary minus (and especially unary plus) is just a bad idea in general; just mandate "0 - expr". To make negative constants work properly, you still have to either special case literals "256", "65536", etc. and ideally check whether they got negated or not, or introduce a special syntax just for them, like "~1" of ML for negative one, or "-1" (which you are not allowed to break with whitespace) of some other language I've forgotten the name of.
While we're at it, probably the unary bitwise complement could go as well? Obviously, "^(0-1)" would suck to write but since 99% of the time bitwise "not" used in expressions/statements like "expr &~ mask..." or "var &= ~mask", I feel like simply having binary "and-not" operator that looks like "&~" or "&^" (Golang) is just better.
Also, a small prize (a "thank you!" from a stranger on the Internet i.e. me) to someone who can propose a good syntax for compound assignment with reversed subtraction:
x ^= 0-1 # in-place bitwise complement
x ^= true # in-place logical negation
x ?= 0 # in-place integer negation???
> Also, a small prize (a "thank you!" from a stranger on the Internet i.e. me) to someone who can propose a good syntax for compound assignment with reversed subtraction:
I would do away with operator-assign operators and instead introduce a general syntax for updating a variable that can be used with any expression.
x = _ + 1 # increment x
x = 0 - _ # negate x
output = sanitizeHtml(_)
index = (_ + 1) % len(arr)
+1 on the convenience of a "mask" operator that perform the and-not. It's an operation that's used more often than others which do have the privilege of having their own symbol, like xor.
Exactly. I genuinely do not understand how any significant user of python can handle white space delimitation. You cannot copy or paste anything without busywork, your IDE or formatter dare not help you till you resolve the ambiguity.
Indeed it does, by showing how many different and confusing types of parsing rules are used in languages that don't have statement terminators. Needing a parser clever enough to interpret essentially a 2-d code format seems like unnecessary complexity to me, because at its core a programming language is supposed to be a formal, unambiguous notation. Not that I'm against readability; I think having an unambiguous terminating mark makes it easier for humans to read as well. If you want to make a compiler smart enough to help by reading the indentation, that's fine, but don't require it as part of the notation.
Non-statement-based (functional) languages can be excepted, but I still think those are harder to read than statement-based languages.
The syntax of languages like Lisp and Forth are so fundamentally different that they don't need an explicit statement separator. You don't have to think about many other things either, or I should say you don't have to think about them in the same way. Consider how much simpler the order of operations is in those languages.
Those are functional languages that generally don't use statements, so it makes sense to leave them out of a discussion about statement separators. If you think more people should use functional languages and so avoid the semicolon problem altogether, you could argue that.
Functional hardly matters Haskell has plenty of indentation which is by the way interchangeable with `{ ... }`, one can use both at one's own pleasure and it's needed for many things.
Also, famously `do { x ; y ; z }` is just syntactic sugar for `x >> y >> z` in Haskell where `>>` is a normal pure operator.
Because formatters are increasingly popular, I think it'd be interesting to see a language that refuses to compile if the code is improperly formatted, and ships with a more tolerant formatter whose behavior can change from version to version. This way, the language can worry less about backwards compatibility or syntax edge cases, at the cost of taking away flexibility from its users.
Are 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...
It's interesting seeing all of the different ways language designers have approached this problem. I have to say that my takeaway is that this seems like a pretty strong argument for explicit end of statements. There is enough complexity inherent in the code, adding more in order to avoid typing a semicolon doesn't seem like a worthwhile tradeoff.
I'm definitely biased by my preferences though, which are that I can always autoformat the code. This leads to a preference for explicit symbols elsewhere, for example I prefer curly brace languages to indentation based languages, for the same reason of being able to fully delegate formatting to the computer. I want to focus on the meaning of the code, not on line wrapping or indentation (but poorly formatted code does hinder understanding the meaning). Because code is still read more than it is written it just doesn't seem correct to introduce ambiguity like this.
Would love to hear from someone who does think this is worthwhile, why do you hate semicolons?
Start from the perspective of the user seeing effectively:
> error: expected the character ';' at this exact location
The user wonders, "if the parser is smart enough to tell me this, why do I need to add it at all?"
The answer to that question "it's annoying to write the code to handle this correctly" is thoroughly lazy and boring. "My parser generator requires the grammar to be LR(1)" is even lazier. Human language doesn't fit into restrictive definitions of syntax, why should language for machines?
> Because code is still read more than it is written it just doesn't seem correct to introduce ambiguity like this.
That's why meaningful whitespace is better than semicolons. It forces you to write the ambiguous cases as readable code.
I used to hate semicolons. Then I started working in parser recovery for rustc. I now love semicolons.
Removing redundancy from syntax should be a non-goal, an anti-goal even. The more redundancy there is, the higher the likelihood of making a mistake while writing, but the higher the ability for humans and machines to understand the developer's intent unambiguously.
Having "flagposts" in the code lets people skim code ("I'm only looking at every pub fn") and the parser have a fighting chance of recovering ("found a parse error inside of a function def, consume everything until the first unmatched } which would correspond to the fn body start and mark the whole body as having failed parsing, let the rest of the compiler run"). Semicolons allow for that kind of recovery. And the same logic that you would use for automatic semicolon insertion can be used to tell the user where they forgot a semicolon. That way you get the ergonomics of writting code in a slightly less principled way while still being able to read principled code after you're done.
Why is ";" different from \n from the perspective of the parser when handling recovery within scopes? Similarly, what's different with "consume everything until the first unmatched }" except substituting a DEDENT token generated by the lexer?
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 < 2 else
"HIGH" if hours < 24 else
"MEDIUM" if hours < 72 else
"LOW"
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.
That's just because most languages go by braces and have optional intendation that is just ignored by the compiler.
I'd reckon that in a language where stuff is done by indentation but optional braces exist that are just ignored so many errors would also have been caused by braces being misplaced by the programmer to queue other programmers who thought some scope happened as a consequence but the compiler disagreed due to the indentation, which by the way was caused by tabs and spaces being mixed in the code and it not properly showing up for another programmer with tab with set differently.
> whitespace/indent languages make it clear there's a lot of redundancy there too.
The only purpose for whitespace indentation is to make the code easier on the eyes. A space shouldn't have an impact in terms of execution, that would be too hazardous. It's too easy to randomly insert a space rather than a character.
> I never find myself just randomly inserting characters.
Hasn't it ever occured to you trying to insert a space at your mouse but your cursor wasn't there? People sometimes forget to click (or think the cursor is already there), myself included. Characters are easier to spot because they are not invisible and random letters cause compile errors.
If it has never occurred to you, then good for you. However I do not see what the benefit of not using closing brackets would be.
I never actually type semicolons in my JavaScript / TypeScript. In work projects, my IDE adds them for me thanks to the linter. In personal projects, I just leave them out (I don't use a linter, so my IDE does not add them), and I've never had a problem. Not even once.
Cormack McCarthy proved to me that when structured correctly conversive language does not need any quotation marks (while remaining entirely comprehensible).
But " " still exist (for us/mere mortals) because few can write so clearly.
I know nothing about coding (beyond changing others' variables to fit my installation), but would imagine this parallels many coding environments (e.g. yours).
I occasionally run into problems with JS weird parsing rules. My favorite is:
return
x
Which does not return. It returns undefined.
Typescript helps a lot with that. A linter will probably flag it as well. Still, JS went way out of its way to accept just about anything, whether it makes sense or not.
> The first thing that I dislike about this is that it encourages thinking of semicolons being inserted instead of statements being terminated
It might, but that's irrelevant since you never think about semicolons in Go at all.
> I like these formatting choices, but I'd prefer if the "wrong style" was still syntactically valid and a formatter would be able to fix it.
Your preference likely comes from some idealistic idea of "cleaniness" or similar, which isn't very convincing. Forcing everyone to use the same style is a huge win, to the point that it's a mistake to do anything else, as seen in the description of what Odin does. Completely wrong priorities there and refusal to learn from the past.
"Code formatting" isn't some inherent property of code that we must preserve at all costs, just a consequence of some unfortunate syntactical choices. There's no inherent reason why a language needs to allow you freedom to choose how to "format" your code. And there are in fact a lot of reasons why it shouldn't.
> 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.
Classic mistakes in language design that have to be fixed later.
- "We don't need any attributes", like "const" or "mut". This eventually gets retrofitted, as it was to C, but by then there is too much code without attributes in use. Defaulting to the less restrictive option gives trouble for decades.
- "We don't need a Boolean type". Just use integers. This tends to give trouble if the language has either implicit conversion or type inference. Also, people write "|" instead of "||", and it almost works. C and Python both retrofitted "bool". When the retrofit comes, you find that programs have "True", "true", and "TRUE", all user-defined.
Then there's the whole area around Null, Nil, nil, and Option. Does NULL == NULL? It doesn't in SQL.
That's what's nice about coarse-grained feature options like Rust's editions or Haskell's "languages", you can opt in to better default behavior and retain compatibility with libraries coded to older standards.
The "null vs null" problem is commonly described as a problem with the concept of "null" or optional values; I think of it as a problem with how the language represents "references", whether via pointers or some opaque higher-level concept. Hoare's billion-dollar mistake was disallowing references which are guaranteed to be non-null; i.e. ones that refer to a value which exists.
> Does NULL == NULL? It doesn't in SQL.
That's because SQL null is semantically different. Most nulls are a concrete value (null pointer). SQL null is the relational null ("not known"). It's closer to NaN (but still different)
Attribute (qualifier), or storage class?
https://www.airs.com/blog/archives/428
The use of 'const' in C is very much a mixed blessing; I certainly have experience of the 'const poisoning' issue. Possibly it would have been better as a storage class.
For bool, yes it was a useful addition. Especially for the cases where old code would have something like:
and that was then combined with logic expecting 'true' to be 1; which could sneak in over time.> 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.
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.
I must disagree but only a tiny bit. modern IDEs try to indent and attempt to add indentation as you code which can cause problems sometimes.
tabs vs spaces is very painful still when copying code that is in a different format. it's not just tabs and spaces, but the width of the tabs and the spaces. Even with VSCode extensions and sublime text extensions I've struggled a lot recently with this.
I commented on a sibling thread just now, but it is still very easy in python to mess up one level of indentation. When I caught bugs of that sort, it was introduced either when copy pasting, when trying to make a linter happy and doing cosmetic cleanup, or when moving code around levels of indentation, like introducing a try/except. I had one recently where if I recall correctly I moved a continue statement under or out of a try/except when messing around with the try/except logic. it was perfectly valid, and didn't stand out much visually, pydnatic and other checkers didn't catch it either. It could have happened with a '}' but it's easier to mess up a level of indentation than it is to put the '}' at the wrong level. a cosmetic fix results in a logic bug because of indentations in python. with curly's, a misplacement of that sort can't happen because of indentation or cosmetic/readability fixes.
what the curly approach asserts is a separation of readability and logic syntax.
The interpreter/compiler should understand your code first and foremost, indenting code should be done, and should be enforced, but automatically by the compiler/interpreter. Python could have used curly braces and semi-colons, and force-indented your code every time it ran it to make it more readable for humans.
we don't even use indents that way in natural language. We use things like bullet points, we need specific markers.
space is for spacing, tabs are for tabulation, they are not in any human language I know of used as terminators of statements. You know what is the equivalent of an indent or a semicolon in english? a period. <-
We have paragraph breaks just like this to delimit blocks of english statements.
A semi-colon is used to indicate part of a sentence is done, yet there is still related continuation of the statement that is yet to be finished. Periods are confusing because they're used in decimal points and other language syntax, so a semi-colon seems like a good fit.
If I had my pick, I would use a colon to indicate the end of a statement, and a double colon '::' to indicate the end of a block.
func main(): int i - 0: do: i=i+1: print(i): while(i<10):: ::
another downside of indentation is it's award to do one-liners with such languages, as with python.
There is a lot of subjectivity with syntax, but python code for example with indents is not easy for humans to read, or for syntax validators to validate. it is very easy for example to intend a statement inside a for loop or an if/else block in python (nor not-intend it), and when pasting around code you accidentally indent one level off without meaning to. if you know to look for it, you'll catch it, but it's very easy to miss, since the mis-indented statement is valid and sensible on its own, nothing will flag it as unusual.
In my opinion, while the spirit behind indentation is excellent, the right execution is in the style of 'go fmt' with Go, where indenting your code for you after it has been properly parsed by the compiler/interpreter is the norm.
I would even say the first thing a compiler as well as interpreter do should be to auto-indent, and line-wrap your code. that should be part of the language standard. If the compiler can't indent your code without messing up logic or without making it unreadable, then either your code or the language design has flaw.
> we don't even use indents that way in natural language.
Have you never seen a nested table of contents?
with apples in that list for example, you used '2.1' to indicate a new item, the space is cosmetic, the functional indicator is '2.1'
This wouldn't look right:
Introduction
I'm sure you can work it out, but it doesn't feel natural, or ideal. (i can't get hn to format it without making it all one line so i used double new line).Your example remains valid after the indentation is stripped, because it has markers to delineate the list and sub list items.
It doesn’t need to; that’s just the section numbering. In a biology textbook, you could have something like (made up names)
and the hierarchy is still clear.it would look better still with a dash or a bullet point for every sub-entry. We're not arguing that it is possible to do that, we're arguing what is ideal for readability.
In that list you can naturally guess what that ordering is, but if the items were not so interrelated it can be confusing. if the top level item is 'Ham' and the indented item under it is 'sandwich' are you wrapping the same phrase 'Ham Sandwich' , because indentation (even in python) is used when wrapping lines, or is sandwich under ham as one of the things done with ham. it is thus error-prone and more confusing, clear and specific punctuation alongside indentation makes it easier to read.
No one is saying that indentation can not be used to display lists/sublists, I'm saying that markers remove ambiguity even across movement of blocks of texts.
Indentation is fragile.
What language is this? In C I get the correct position of the error because GCC also monitors the indentation as it parses.
A linter can point out errors based on indentation, and they frequently do. There's no need for the language to do it and then band-aid additional fixes for problems caused by significant white space.
rustc does exactly that keeping the indent level of every unbalanced curly brace. It works OK, but it isn't perfect by any stretch. More heuristics are needed.
> 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.
That's somewhat a quality of service issue though. Compilers should look at where the braces go out of kilter vs indentation and suggest the possible unmatched opening brace.
Scala 3 decided to go with indents.
You are not telling the whole story.
You can mix indentation and braces to delimit blocks.
It's insane.
As a casual observer who has written perhaps a dozen lines of Scala in his life, I feel like Scala approaches any “pick one” decision with “why not both?”.
Functional or OO? Yes.
I personally think this put the final nail in the coffin.
I like how Haskell does it. One can do both but not mix, as in either indent or use `{ ... }`.
Kind of. It supports an end operator as well, and imo everyone should be using it. I actually really like the `end name` approach as opposed to the Lua-style plain ends.
The issue is that you find you very often want to break those roles. Python basically has `elif` because `else if` would make each branch nest one level deeper which isn't what one wants, except Python uses exceptions for flow control so you find yourself having to use `except ... try` as an analogue to `else if` but not `excetry` exists to do the same and stop the indentation.
There are many other examples. It exists to give people freedom. Also, while humans only go by intendation it's very hand for text editing and manipulation without requiring special per-language support to move the cursor say to the nearest closing brace and so forth.
> Python basically has `elif` because `else if` would make each branch nest one level deeper which isn't what one wants
There are, of course, other ways to handle this. For instance, "else if <cond>:" could've been made legal à la Golang:
I'm very okay with elif though because it makes it clear that the conditional is part of the chained block and not a brand new one.
The issue is that it's a special case that acknowledges where there are cases where the indentation level it logically requires isn't what programmers find pleasant, there are many more, that just don't have that special case, so it forces indentation that's unpleasant and unintuitive.
Perhaps having unary minus (and especially unary plus) is just a bad idea in general; just mandate "0 - expr". To make negative constants work properly, you still have to either special case literals "256", "65536", etc. and ideally check whether they got negated or not, or introduce a special syntax just for them, like "~1" of ML for negative one, or "-1" (which you are not allowed to break with whitespace) of some other language I've forgotten the name of.
While we're at it, probably the unary bitwise complement could go as well? Obviously, "^(0-1)" would suck to write but since 99% of the time bitwise "not" used in expressions/statements like "expr &~ mask..." or "var &= ~mask", I feel like simply having binary "and-not" operator that looks like "&~" or "&^" (Golang) is just better.
Also, a small prize (a "thank you!" from a stranger on the Internet i.e. me) to someone who can propose a good syntax for compound assignment with reversed subtraction:
> Also, a small prize (a "thank you!" from a stranger on the Internet i.e. me) to someone who can propose a good syntax for compound assignment with reversed subtraction:
I would do away with operator-assign operators and instead introduce a general syntax for updating a variable that can be used with any expression.
+1 on the convenience of a "mask" operator that perform the and-not. It's an operation that's used more often than others which do have the privilege of having their own symbol, like xor.
This article makes a strong case for every language to use ‘;’ as a statement separator.
Exactly. I genuinely do not understand how any significant user of python can handle white space delimitation. You cannot copy or paste anything without busywork, your IDE or formatter dare not help you till you resolve the ambiguity.
One day https://github.com/mathialo/bython one day!
> You cannot copy or paste anything without busywork
Sounds like a tool issue. My editor (Neovim with a few plugins) can handle copying/pasting with indentation just fine.
> your IDE or formatter dare not help you
Get the ones that do help you! Problem solved, enjoy your clean reading experience!
looks cool..
Alternatively, I've several times used 'pass' as block terminator for my personal code.
Indeed it does, by showing how many different and confusing types of parsing rules are used in languages that don't have statement terminators. Needing a parser clever enough to interpret essentially a 2-d code format seems like unnecessary complexity to me, because at its core a programming language is supposed to be a formal, unambiguous notation. Not that I'm against readability; I think having an unambiguous terminating mark makes it easier for humans to read as well. If you want to make a compiler smart enough to help by reading the indentation, that's fine, but don't require it as part of the notation.
Non-statement-based (functional) languages can be excepted, but I still think those are harder to read than statement-based languages.
Lisps aren’t necessarily functional, but don’t need semicolons either.
The syntax of languages like Lisp and Forth are so fundamentally different that they don't need an explicit statement separator. You don't have to think about many other things either, or I should say you don't have to think about them in the same way. Consider how much simpler the order of operations is in those languages.
Lisp has explicit "statement" terminators (just aren't semicolons)
All the lisps I know of have only expressions (no statements).
Looks at 11 languages, ignores Haskell or anything really different...
Once I learned Haskell, everything else looks pretty much identical. Java, C, C++, Smalltalk... At least Lisp looks a little bit different.
or Raku
Those are functional languages that generally don't use statements, so it makes sense to leave them out of a discussion about statement separators. If you think more people should use functional languages and so avoid the semicolon problem altogether, you could argue that.
Yet, the author ends with a half-backed clone of the Haskell syntax.
Functional hardly matters Haskell has plenty of indentation which is by the way interchangeable with `{ ... }`, one can use both at one's own pleasure and it's needed for many things.
Also, famously `do { x ; y ; z }` is just syntactic sugar for `x >> y >> z` in Haskell where `>>` is a normal pure operator.
Because formatters are increasingly popular, I think it'd be interesting to see a language that refuses to compile if the code is improperly formatted, and ships with a more tolerant formatter whose behavior can change from version to version. This way, the language can worry less about backwards compatibility or syntax edge cases, at the cost of taking away flexibility from its users.
> I would love to see a language try to implement a rule where only an indented line is considered part of the previous expression.
Elm does this (so maybe Haskell too). For example
how to handle expressions that need more than two lines?
Are 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...
The Haskell language report precisely defines how layout determines structure: https://www.haskell.org/onlinereport/haskell2010/haskellch10...
Any language that uses layout to determine structure should have a similarly precise definition.
It's very subjective, and I don't want to say that semicolons are good or bad, indentation is good or bad, etc.
But I think a language should decide whether white space is significant or not. If it's not, don't add exceptions!
Operators changing meaning when surrounded by spaces in otherwise context-free languages are an abomination!
> Operators changing meaning when surrounded by spaces in otherwise context-free languages are an abomination!
How does that make the language not context-free?
It's interesting seeing all of the different ways language designers have approached this problem. I have to say that my takeaway is that this seems like a pretty strong argument for explicit end of statements. There is enough complexity inherent in the code, adding more in order to avoid typing a semicolon doesn't seem like a worthwhile tradeoff.
I'm definitely biased by my preferences though, which are that I can always autoformat the code. This leads to a preference for explicit symbols elsewhere, for example I prefer curly brace languages to indentation based languages, for the same reason of being able to fully delegate formatting to the computer. I want to focus on the meaning of the code, not on line wrapping or indentation (but poorly formatted code does hinder understanding the meaning). Because code is still read more than it is written it just doesn't seem correct to introduce ambiguity like this.
Would love to hear from someone who does think this is worthwhile, why do you hate semicolons?
Start from the perspective of the user seeing effectively:
> error: expected the character ';' at this exact location
The user wonders, "if the parser is smart enough to tell me this, why do I need to add it at all?"
The answer to that question "it's annoying to write the code to handle this correctly" is thoroughly lazy and boring. "My parser generator requires the grammar to be LR(1)" is even lazier. Human language doesn't fit into restrictive definitions of syntax, why should language for machines?
> Because code is still read more than it is written it just doesn't seem correct to introduce ambiguity like this.
That's why meaningful whitespace is better than semicolons. It forces you to write the ambiguous cases as readable code.
I used to hate semicolons. Then I started working in parser recovery for rustc. I now love semicolons.
Removing redundancy from syntax should be a non-goal, an anti-goal even. The more redundancy there is, the higher the likelihood of making a mistake while writing, but the higher the ability for humans and machines to understand the developer's intent unambiguously.
Having "flagposts" in the code lets people skim code ("I'm only looking at every pub fn") and the parser have a fighting chance of recovering ("found a parse error inside of a function def, consume everything until the first unmatched } which would correspond to the fn body start and mark the whole body as having failed parsing, let the rest of the compiler run"). Semicolons allow for that kind of recovery. And the same logic that you would use for automatic semicolon insertion can be used to tell the user where they forgot a semicolon. That way you get the ergonomics of writting code in a slightly less principled way while still being able to read principled code after you're done.
Why is ";" different from \n from the perspective of the parser when handling recovery within scopes? Similarly, what's different with "consume everything until the first unmatched }" except substituting a DEDENT token generated by the lexer?
Can anyone give a good reason why supporting syntax like:
is worth it?in Haskell, supporting that is how you get neat composition
such as applicative style formatted like this:
By "is worth it" you mean it's worth the work?
Because it's very little extra work.
If you want to know if it's a good syntax, AFAIK it's the only way to do a semicolon-less language that doesn't break all the time.
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.
Mostly eye-candy, especially for some long one-liners.
In PowerShell you can do that by explicitly instructing what the next line is actually a continuation of the previous one:
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.
That's just because most languages go by braces and have optional intendation that is just ignored by the compiler.
I'd reckon that in a language where stuff is done by indentation but optional braces exist that are just ignored so many errors would also have been caused by braces being misplaced by the programmer to queue other programmers who thought some scope happened as a consequence but the compiler disagreed due to the indentation, which by the way was caused by tabs and spaces being mixed in the code and it not properly showing up for another programmer with tab with set differently.
> tabs and spaces being mixed in the code
Python banned this in python3. Problem solved.
> 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.
Javascript's delimeter soup ((){([]{})}); can become near impossible to parse barebrained, especially when mixed with indents and semicolons.
Semicolons are just noise. They're absolutely redundant.
Some brackets are necessary, but whitespace/indent languages make it clear there's a lot of redundancy there too.
The goal is to minimise errors and cognitive load. The fewer characters the better.
> whitespace/indent languages make it clear there's a lot of redundancy there too.
The only purpose for whitespace indentation is to make the code easier on the eyes. A space shouldn't have an impact in terms of execution, that would be too hazardous. It's too easy to randomly insert a space rather than a character.
> It's too easy to randomly insert a space rather than a character.
What are you doing with your code? I never find myself just randomly inserting characters.
> I never find myself just randomly inserting characters.
Hasn't it ever occured to you trying to insert a space at your mouse but your cursor wasn't there? People sometimes forget to click (or think the cursor is already there), myself included. Characters are easier to spot because they are not invisible and random letters cause compile errors.
If it has never occurred to you, then good for you. However I do not see what the benefit of not using closing brackets would be.
I don’t use the mouse when editing code, so this particular mistake does not happen to me.
> I do not see what the benefit of not using closing brackets would be.
Less visual noise. And the ability to use braces for other syntax.
> and not realizing the braces don't match.
Make your IDE highlight the current section or display a hint showing starting bracket. For example, C++ devs do #endif // #if ...
Too many brackets? Refactor - problem solved.
IMO, that is the only acceptable situation where semicolons can be removed from the language... if you need to add indentation rules, you've failed.
I never actually type semicolons in my JavaScript / TypeScript. In work projects, my IDE adds them for me thanks to the linter. In personal projects, I just leave them out (I don't use a linter, so my IDE does not add them), and I've never had a problem. Not even once.
Semicolon FUD is for the birds.
Cormack McCarthy proved to me that when structured correctly conversive language does not need any quotation marks (while remaining entirely comprehensible).
But " " still exist (for us/mere mortals) because few can write so clearly.
I know nothing about coding (beyond changing others' variables to fit my installation), but would imagine this parallels many coding environments (e.g. yours).
I occasionally run into problems with JS weird parsing rules. My favorite is:
Which does not return. It returns undefined.Typescript helps a lot with that. A linter will probably flag it as well. Still, JS went way out of its way to accept just about anything, whether it makes sense or not.
That is what I lament too. So I've started to use the comma-operator to make sure my return statements don't care about line-breaks. I often write:
return 0,
x;
I find this a mildly amusing discovery for myself because it took me a long time to figure out a useful use for the comma-operator.
> The first thing that I dislike about this is that it encourages thinking of semicolons being inserted instead of statements being terminated
It might, but that's irrelevant since you never think about semicolons in Go at all.
> I like these formatting choices, but I'd prefer if the "wrong style" was still syntactically valid and a formatter would be able to fix it.
Your preference likely comes from some idealistic idea of "cleaniness" or similar, which isn't very convincing. Forcing everyone to use the same style is a huge win, to the point that it's a mistake to do anything else, as seen in the description of what Odin does. Completely wrong priorities there and refusal to learn from the past.
"Code formatting" isn't some inherent property of code that we must preserve at all costs, just a consequence of some unfortunate syntactical choices. There's no inherent reason why a language needs to allow you freedom to choose how to "format" your code. And there are in fact a lot of reasons why it shouldn't.
> 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.
[flagged]