Allow ending statements with newlines.

[somerandomdev49]

Added token type NEWLINE.
Added newlines to parseStatementExpression
I forgot parseReturnStatement.
:)

[somerandomdev49]

Also, you should add a loop in the parser’s parseStatement that looks something like this:

for currToken.type == token.SEMICOLON || currToken.type == token.NEWLINE {
    p.nextToken()
}

[liamross]

Thanks so much for this, it's definitely something I want to work towards. However, I'm afraid just allowing new lines to end isn't enough (I wish it was).

Take this for example:

add = fn(a, b) {  // new line here... it thinks this is the end of the statement (wrong)
    return a + b; // semicolon and newline here, it thinks this is the end of the statement (correct)
}                 // new line here (this is fine, since it is technically the end. However that was already detected by end of block statement)

The approach I want to eventually implement is to make smart rules around which new lines are valid end-of-statements (similar to how Go does it under the hood. Technically, it is inserting semicolons in all the spots where the newline indicates a correct end of statement). For example, we could safely assume a new line after any of these: {, [, ( is not a valid end of statement, so we wouldn't insert a semicolon.

I haven't actually tested the above approach so I'm just guessing as to whether that will be the final design of it, but I think it's a good start in terms of removing all semicolons. I actually would like to go as far as to not have semicolons be present (unless maybe to split up for loop args and stuff like Go).

[liamross]

On that note, I did notice Go does it a bit differently where they have a flag for whether to add a semicolon before the end of the next line see here. I would have thought that just having a list of tokens after which you disallow the insertion of a semi would be enough, but perhaps the Go devs ran into issues with that approach.

Edit: I think it may be because Go has a strict syntax. For example you can't put things after a }, you need to have a new line, and increment / decrement has to be on it's own line. Since my syntax won't be as strict, I think my whitelist symbol approach might work out just fine.

[somerandomdev49]

Thanks for the response :D

But newline after the { would be consumed by parseStatement. And! You should add the same loop that skips newlines and semicolons to parseStatement (add a wrapper function with a temp. value and add the loop before and after) or allow empty statements (I don’t remember if the parser does that, if it does, sorry :) ) so that newlines and semicolons before } would be ignored.

[liamross]

Interesting, yeah I'll take a look at implementing something and update with what I find.