adding a nimbleparse.toml

[ratmice]

I've been thinking of trying to write a nimbleparse-lsp which can be used to automatically run nimbleparse on various test input when editing grammars.

For this, I think it would be nice to have something like a nimbleparse.toml which specifies lexer, parser, yacc kind, error recovery style, and either test inputs or file extension for inputs and test input directories.

Then, when running nimbleparse with no options or --toml or --toml nimbleparse.toml would run over the various test cases. We could also add an option to CTLexerBuilder, e.g. process_toml (In which case calling it nimbleparse.toml) might need a different name to specify the lexer and parsers.

Is this a thing you all would be interested in having integrated into either nimbleparse or the builder API, or would it be best to experiment with it in the lsp server first in isolation and figure out the details there?

[ltratt]

My immediate reaction is that this sounds very cool, but perhaps would best sit in its own repository? In a sense, nimbleparse almost isn't a "thing" -- it's just a minimal front-end (<200LoC) around the back-end libraries to show what's possible, and it has no additional privileges above any other library. I think a nimbleparse-ish-LSP-ish tool also would need no additional privileges?

FWIW, I think it would be cool to do things like "randomly generate inputs as testing" (sort of hypothesis-for-grammars) perhaps in the vein of Krish's thesis. That might fit quite well in what you're thinking?

[ratmice]

Yeah, I suspect if the API is good enough for nimbleparse, it should work fine for lsp as well. randomly generating inputs probably would probably be nice, I don't seem to be able to access the thesis host at the moment.

For the first run i'm probably just going to throwing it at directories with a file extension, and setting a boolean on those directories input should pass/fail.

I think my rationale for proposing adding the toml to grmtools proper is that since the lsp server needs the .l, and .y file locations, if grmtools knew about the toml, you could avoid specifying it in two places.

Either as an external repo or including it here are both fine with me, I think it definitely worthwhile to start off external at least until we figure out it's churn rate then we could revisit it at any time if it ever makes sense to include it.

[ltratt]

I've pinged Krish about his site -- the wayback machine has a link which hopefully works in the meantime though https://web.archive.org/web/20200927102847/http://navkrish.net/pubs/phd_thesis.pdf.

Either as an external repo or including it here are both fine with me, I think it definitely worthwhile to start off external at least until we figure out it's churn rate then we could revisit it at any time if it ever makes sense to include it.

Good idea! It probably makes sense to do development somewhere external at first (I'm happy to comment on it!) then, when it's in good shape, have a think about whether it might make sense to integrate or not.

[ratmice]

Cool, I think then we can just close this for now then, and i'll update with a repo URL once i've got it something to look at?

[ratmice]

FWIW, https://github.com/ratmice/nimbleparse_lsp

This currently doesn't really do anything (basic hello world), Except read the nimbleparse.toml and associate the extension therein with the language server that is a start, anyhow.

[ltratt]

Looks cool! Why don't we track this on your repo? You can ping me there when you think it's useful.

[I'm not a VSCode person, though, so I won't be able to test it, but I might be able to add a comment or two!]

[ratmice]

Indeed.