[HN Gopher] No Semicolons Needed
___________________________________________________________________
No Semicolons Needed
Author : karakoram
Score : 24 points
Date : 2026-03-21 19:07 UTC (3 hours ago)
(HTM) web link (terts.dev)
(TXT) w3m dump (terts.dev)
| gcanyon wrote:
| Can anyone give a good reason why supporting syntax like:
| y = 2 * x - 3
|
| is worth it?
| whateveracct wrote:
| in Haskell, supporting that is how you get neat composition
|
| such as applicative style formatted like this:
| f <$> x <*> y <*> z
| szmarczak wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| marcosdumay wrote:
| 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.
| justsomehnguy wrote:
| 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
| zephen wrote:
| 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"
| marcosdumay wrote:
| Looks at 11 languages, ignores Haskell or anything really
| different...
| librasteve wrote:
| or Raku
| Animats wrote:
| 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.
| sheept wrote:
| > 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
| sheept wrote:
| 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.
| librasteve wrote:
| This article makes a strong case for every language to use ';' as
| a statement separator.
| bmandale wrote:
| > 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.
| vips7L wrote:
| Scala 3 decided to go with indents.
| kayson wrote:
| 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.
| stinkbeetle wrote:
| > 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.
| IshKebab wrote:
| > 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.
| kayson wrote:
| 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...
| gethly wrote:
| garbage
___________________________________________________________________
(page generated 2026-03-21 23:00 UTC)