More helpful syntax error messages

[anko]

Syntax errors look like this right now:

$ eslc <<< "("

/home/an/code/eslisp/node_modules/sexpr-plus/index.js:1054
      throw peg$buildException(null, peg$maxFailExpected, peg$maxFailPos);
      ^
SyntaxError: Expected ")", comment or whitespace but end of input found.

The SyntaxError-object sexpr-plus returns has line and column properties. We should perhaps use them.

---

Invalid AST errors look like this:

$ eslc <<< "(+ x %)"
{ [InvalidAstError: Identifier `name` member must be a valid IdentifierName]
  node: { type: 'Identifier', name: '%' },
  message: 'Identifier `name` member must be a valid IdentifierName' }
x + %;

That's already getting there, but it would still be best if exact positions in code were passed on to AST nodes, so the error reporter could point out the exact in-source position that an error happened.

[anko]

Here's what we have as of bf7bb54, shown in the REPL:

An illegal identifier occurring in a built-in macro is highlighted in source. This should work with any error returned by esvalid, but I haven't tested it comprehensively.

As you can see in the last command, the invalid AST node originating from the user-defined macro nonsense isn't shown with highlighted source. This is because macros aren't necessarily even in the source: they may have been required from another module or themselves generated by another macro.

It would be good to at least display the macro's name ([ returned from macro 'nonsense' ]), but macro return values are not currently tagged with that information.

[dead-claudia]

@anko

Could this be implemented via an env::fail() method? That could also be potentially useful for macro writers as well, if they need to fail with a more descriptive error than simply "Oh, by the way, this will break if you're not careful", which is a common problem with macros, especially when you're dealing with DSLs.

I was just thinking of this when I was working on #41. That as a high-level method might be the best way to do it, and it would definitely be worth exposing.

[anko]

@isiahmeadows I've just had macros throw an error when user input is nonsensical.

However, the compilation env makes no attempt to catch errors from macros at the moment. Hence the stack traces don't tell you useful stuff e.g. which macro it was that errored. I think catching would be a better way than an env::fail, because something the macro-writer didn't think to check for might throw an error too.

[anko]

f19be37 now catches macro errors and adds diagnostic data before rethrowing. Thanks for raising that.