RedPRL
Parse errors?
@freebroccolo When the parser fails, I'd like it to emit some minimal message that tells me what went wrong; it doesn't need to be a good message (for instance, I don't yet have the bandwidth to develop fancy custom error messages like you seem to have done in yggdrasil). Ideally, it would just be a kind of crappy message like you get by default with these parser generators.
Do you know how to enable that behavior? There was some commented code Parse.ml, but I didn't really understand it.
I haven't looked too deeply into the error message capabilities of recent Menhir. My impression is that the easiest way to get decent error messages without using the introspection API (and the extra work that entails) is to use the .messages metadata stuff. I'd have to take a look at the manual again but I think basically you can describe some sort of patterns for invalid states along with boilerplate messages such that if the parser encounters them it uses those messages.
Maybe another way you can get basic error messages is by ditching the incremental API (in this case, using the built-in driver and ditching the custom parse loop in Parse.ml). This would mean you'd have to remove the async IO via Lwt though I think. There may be some functions in the Menhir API that let you reconstruct the standard error messages even when you are using the incremental API but I'm not familiar enough with Menhir to know for certain.
I see, thank you for the info!
I briefly checked out the .messages stuff and it seems pretty neat; I wasn't able to figure out how to unleash it with dune, but it seems possible. My one concern is I guess that prior to the solidification of the language, this is not so maintainable: every time I change the parser, this would probably result in the need for non-trivial changes to the .messages file. Menhir can be passed some option to check whether your .messages file is complete, but all this makes it quite hard to develop a project whose syntax is not anywhere near set in stone.
I guess the other option (ditching the incremental API) might work, though this too would be kind of a shame. Seems like that stuff is pretty cool and might let us do some very neat stuff in the future.
I'll keep thinking about it, though.