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.
bmandale 1 hours ago [-]
> 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.
kayson 56 minutes ago [-]
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.
vips7L 1 hours ago [-]
Scala 3 decided to go with indents.
stinkbeetle 51 minutes ago [-]
> 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.
librasteve 1 hours ago [-]
This article makes a strong case for every language to use ‘;’ as a statement separator.
sheept 1 hours ago [-]
> 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
x = "hello "
++ "world"
y = "hello "
++ "world" -- problem
marcosdumay 1 hours ago [-]
Looks at 11 languages, ignores Haskell or anything really different...
19 minutes ago [-]
librasteve 1 hours ago [-]
or Raku
sheept 1 hours ago [-]
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.
kayson 55 minutes ago [-]
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...
gcanyon 2 hours ago [-]
Can anyone give a good reason why supporting syntax like:
y = 2 * x
- 3
is worth it?
whateveracct 2 hours ago [-]
in Haskell, supporting that is how you get neat composition
such as applicative style formatted like this:
f
<$> x
<*> y
<*> z
marcosdumay 1 hours ago [-]
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.
zephen 1 hours ago [-]
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 < 2 else
"HIGH" if hours < 24 else
"MEDIUM" if hours < 72 else
"LOW"
justsomehnguy 1 hours ago [-]
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:
$y = 2 * $x `
- 3
szmarczak 1 hours ago [-]
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.
bmandale 1 hours ago [-]
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.
szmarczak 51 minutes ago [-]
> 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.
TheOtherHobbes 13 minutes ago [-]
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.
IshKebab 1 hours ago [-]
> 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.
gethly 27 minutes ago [-]
garbage
Rendered at 23:16:36 GMT+0000 (Coordinated Universal Time) with Vercel.
- "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.
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.
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.
Elm does this (so maybe Haskell too). For example
such as applicative style formatted like this:
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.
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.
In PowerShell you can do that by explicitly instructing what the next line is actually a continuation of the previous one:
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.
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.
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.