Can anyone give a good reason why supporting syntax like:

    y = 2 * x
      - 3

is worth it?

        f
    <$> x
    <*> y
    <*> z

    $y = 2 * $x `
       - 3

  priority = "URGENT"  if hours < 2  else
             "HIGH"    if hours < 24 else
             "MEDIUM"  if hours < 72 else
             "LOW"

Looks at 11 languages, ignores Haskell or anything really different...

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.

> 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

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.

This article makes a strong case for every language to use ‘;’ as a statement separator.

> 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.

> 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.

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...

garbage