Hacker News Reader

Comment by gpm | Hacker News Reader

Someone correct me if I'm wrong, but I think the semi-colons main purpose is to make error messages better. It makes it easy to say "well, the previous malformed statement definitely finishes by here".

View on HN

And to avoid all the horrible edge-cases that can arise when the parser has to work out whether the next line is a continuation of the same statement or not.

For example in JS:

  var x = y.z
  [a, b, c].forEach(doIt)

parses to:

  var x = y.z[a, b, c].forEach(doIt)

rather than the two statements that were clearly intended.

There are a bunch of reasons why this is more of an issue in JavaScript than it is or would be in most languages. The early incarnations of the language practically leaned into bad parsing logic and it's permanently stuck with them now.

But in particular any strongly typed language is gonna need some really convoluted code to produce similar ambiguities that actually make it to linking.

I think the most likely "bad" outcome of semicolon-less rust would be losing the hanging dot function chaining people do so much in rust, but even that's not a guarantee.

This was almost prevented from the get go. Brendan Eich tried to implement scheme in the browser. But the business people asked him to make it look like Java. :(

> But in particular any strongly typed language is gonna need some really convoluted code to produce similar ambiguities that actually make it to linking.

Even if it's a compiler error, what are you supposed to do when the compiler returns the error from the snippet above?

I think you'll need to come up with an example that exploits a weakness in rust's grammar for me to answer that? The above js example I don't think it would make sense to have rust erase the newline to begin with..

I think the main way that people hang syntax like this in rust is with chained .methods, and since . at the start of a statement isn't valid rust to begin with it could probably be unambiguously be allowed anyways.

But I wouldn't expect:

    a
    [1]

To be considered valid specifically because of the potential ambiguity of a single term array and a suffix index. It's also not really common right now anyways, afaik.

JavaScript tries to be way too damn clever here and no one is ever going to seriously suggest anything try to replicate "automatic semicolon insertion". Just don't allow line joins when it makes the next line ambiguous.

Interestingly it would be possible to come up with a straw man parser that makes semicolons optional and then run it through the whole "recompile every crate" thing the rust project has to see if it would cause new failures. It would be an interesting project tbh.

It's a problem in Python too, but in the opposite direction in that Python is too eager to parse multiple lines as multiple expressions instead of a single expression, forcing you to add parentheses everywhere.

  1 +
  2

is a syntax error, you need to make it

  1 + (
  2)

also :

    foo.bar()
    .1 + baz()

parses to

    foo.bar().1 + baz()
             ^^ = undefined

Nope. 1 is not a property name that can be used with the dotted notation because it begins with a figure.

foo.bar().1 + baz() gives:

    Uncaught SyntaxError: unexpected token: numeric literal

The following:

    foo.bar()
    .1 + baz()

is equivalent to:

    foo.bar();
    .1 + baz();

The parser will find this syntax error, backtrack and insert a semicolon (Automatic Semicolon Insertion applies).

Interestingly, I tried to run the following in the browser console:

    {}.1

And it runs. It gives 0.1. This is probably because {} is interpreted as an empty block (of statements), I guess. The following gives the same result:

    {};.1

The following is a parse error:

    ({}).1

I tried the following to convince myself that {} is evaluated as an empty block, so I went further.

The following works:

    {a:2}.1

... because a: is a label. you really need to try with "two properties" to see a syntax error:

    {a:2, b:2}.1

Gives: Uncaught SyntaxError: unexpected token: ':' (character 7). A label cannot be introduced after the comma operator... (yes, because it is a comma operator! {a:2, console.log("hello")}.1 prints "hello" and its result is 0.1)

(WAT?)

edit: {;}.1 and {;;}.1 also work of course.

> Nope. 1 is not a property name that can be used with the dotted notation because it begins with a figure.

Oops, you're right.

JavaScript's algorithm for this is dumb. There are better ways to do it, as seen in Python, Ruby, Nim, …

Because not all statements in a block have to end in a semicolon, and most things at module scope don't, rust fails at this anyways imo. Without an editor's help I'm pretty frequently lost finding the missing balancer for an open brace or parenthesis.

Reply on news.ycombinator.com