Great work! Would love some help diagnosing syntax errors

[tcoulter]

Hey there! I realize Github issues aren't meant for support, though I wanted to get your thoughts on an issue I'm having.

To start, thank you for all the great work. I'm super excited about tspeg and it's exactly what I want for my TS project.

Now to the issue I'm having. Using the default toString() method on syntax errors, I'm receiving this on code that should parse:

Syntax Error at line 25:0. Expected one of  '\s', '\/\*[^(\*\/)]*\*\/', '\/\/[^(\n)]*\n', ';', '>\=', '>', '<', 'p', 'p@', 'i', 'r', '!', EOF

Of course, you don't know the grammar I've written, but that's kind of the point. There doesn't appear to be enough information in this syntax error (or the SyntaxErr object) to direct me, the language developer, or language users what's wrong.

For me, I'd love to know if my parser is parsing incorrectly. I think that's the case. But it's too hard for me to diagnose. What I'd need to know is A) what rule it was currently trying to parse, and B) what rules have already been matched. Knowing that, I'd be able to tell why the rule I expected to match wasn't matched.

For the user, I'd need more context around the error in order to direct the user what to do. For instance, the SyntaxErr object doesn't have enough information (primarily A above) telling me what the parser was trying to parse, so I can tell that information to the user. e.g., if I knew the rule, I could throw an error like this: Arithmetic operation expected symbol of "+", "-", "/", or "*"; instead, received X. This is super contrived, but point is, being aware of the rule that failed would help tremendously.

I'd absolutely love to contribute back if you could direct me on a good place to start. Again, really love your work so far and I appreciate everything you've done.

On the off chance I'm completely missing something obvious that would solve this, would love to hear it! Sans changing how tspeg works, I'm thinking of abusing computed properties on every rule to print out debug information. It won't be pretty, but will get the job done (I think; still need to try it).

Thanks again! And thanks for letting me use Github issues for support!

[tcoulter]

Wanted to jump back in to confirm that hijacking conditional arguments does in fact work. I chose to use the debug library, and added the following to the top of my grammar:

---
import debug from "debug";
const debugRule = debug("rules")
---

And here's an example of how I'm using it (shortened to remove unnecessary info):

Command :=
  command={Halt 
  | MoveRight
  | MoveLeft
  | SetPixel
  // ... others
  }
  .debug = void {debugRule(this.kind, this.command.kind)}

When DEBUG=rules is set, it gives the following. It already showed me that I need to make my whitespace rule greedier!

All this is to say that it'd be really helpful to see what the parser has parsed already, especially when there's an error.

Thanks again for the great work!