Closed tjvr closed 5 years ago
I don't really have a problem with formatError()
interpreting null/undefined as EOF, but it seems confusing and unreadable to write code that uses tok
outside of its logical scope to mean the constant undefined
. Even though the example above uses a while loop, it reads as a for loop:
for (let tok; tok = lexer.next();) {
try {
parser.eat(tok)
} catch (err) {
throw new Error(lexer.formatError(tok, "Syntax error"))
}
}
which makes using it outside of the loop unintuitive and odd. I think it makes more sense to write the second call to formatError()
as
lexer.formatError(null, "Unexpected EOF")
or simply
lexer.formatError("Unexpected EOF")
Additionally, perhaps such a call should use the current lexer position rather than always use EOF; it would be odd to call formatError in the middle of the token stream and have the result point to its end.
Sounds good. I think my comment above may still be relevant:
perhaps such a call should use the current lexer position rather than always use EOF; it would be odd to call formatError in the middle of the token stream and have the result point to its end.
Awesome, thanks! LGTM
It's fairly natural to write code of the form:
The second
formatError
call is not valid, becausetok
will beundefined
here. Moo usesundefined
to indicate that there are no more tokens, i.e. we've reached the end of the buffer.There's no way to get Moo to format an error at the end of the file, after the last token, without manually constructing an EOF token. I propose letting
formatError
acceptundefined
, and silently interpret it as an EOF token.Alternatively, we could introduce a
lexer.makeEOF()
method which returns this end-of-file token directly.