I have finished implementing and testing a working meta-level parser. This PR is based on #119.
It works for grammars that do not make complex use of side conditions or functions. The tests contain simple examples of using the Wasm grammar for parsing LEBs, types, or even empty modules. that already uncovered a few minor bugs in our Wasm grammar, which is good. :)
However, the main roadblock for making it fully work is that the IL (as we know) is not quite algorithmic enough for performing reduction. Hence in general, the parser barfs when it encounters non-trivial side conditions with bindings.
A possible solution would be to run the animation transformation first. I haven't tried that yet. Or of course, we make bindings more explicit in the EL already.
But it'll also require dealing with inverted functions. Given that the AL backends already jump through hoops for dealing with this, I wonder if we should have a cleaner way for supporting function inversion, one that doesn't require hardcoding, but where the user defines the inverses.
Anyway, this is just a status update to prepare everybody that I'd like to discuss this more in due time. Right now it isn't the highest priority.
I have finished implementing and testing a working meta-level parser. This PR is based on #119.
It works for grammars that do not make complex use of side conditions or functions. The tests contain simple examples of using the Wasm grammar for parsing LEBs, types, or even empty modules. that already uncovered a few minor bugs in our Wasm grammar, which is good. :)
However, the main roadblock for making it fully work is that the IL (as we know) is not quite algorithmic enough for performing reduction. Hence in general, the parser barfs when it encounters non-trivial side conditions with bindings.
A possible solution would be to run the animation transformation first. I haven't tried that yet. Or of course, we make bindings more explicit in the EL already.
But it'll also require dealing with inverted functions. Given that the AL backends already jump through hoops for dealing with this, I wonder if we should have a cleaner way for supporting function inversion, one that doesn't require hardcoding, but where the user defines the inverses.
Anyway, this is just a status update to prepare everybody that I'd like to discuss this more in due time. Right now it isn't the highest priority.