You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently use/abuse conjure's parser - at some point we need to implement a parser in Rust.
This needs to be tested thoroughly against the existing parser. Both for well-formed input and for error messages. To be clear: the error messages do not have to be identical, but shouldn't be worse than those of the existing parser.
This project has clear boundries and can be achieved by one student. Could also be an SH project.
The text was updated successfully, but these errors were encountered:
We do want the parser to interleave name-resolution, type-checking, category checking etc as well for the best possible error messages. Tree-sitter seems to work well with syntax highlighting, and LSP-like functionality which is great.
This may be a bad suggestion, but I wonder if we could do "error-driven development"? In my experience, getting a parse which produces the correct answer for correct inputs isn't too hard, but getting good error messages out is very hard, and also hard to do afterwards, when your parser is already written.
The difficulty (as I understand it) is choosing when to 'commit' to a partial parse, else your parser ends up saying "I tried to parse this whole document, and I failed".
An early version of conjure used to almost always print (I think?) 'unexpected g' whenever it was given invalid input, and this made using Conjure very difficult.
I can talk about the 'unexpected g' fame at lenght if people are interested :)
On the bright side Chris, we now have a good bunch of well-formed and otherwise Essence files. And we can compare the error messages to those of Conjure's existing parser. So I think it'll be a bit easier this time, given a good parsing library.
We currently use/abuse conjure's parser - at some point we need to implement a parser in Rust.
This needs to be tested thoroughly against the existing parser. Both for well-formed input and for error messages. To be clear: the error messages do not have to be identical, but shouldn't be worse than those of the existing parser.
This project has clear boundries and can be achieved by one student. Could also be an SH project.
The text was updated successfully, but these errors were encountered: