Open kanha-gupta opened 7 months ago
Hi @andreaTP, as you mentioned that we can either enable core parser functionalities first or enable custom parsers. What do you think is the right approach ?
No super strong opinion as far as we can get this effort started.
A possible approach would be to extract an interface
for the Parser functionality.
The BinaryParser
implementation will be the current implementation, and we should make the Parser
instance injectable here.
In this way implementing new Parsers should be straightforward. wdyt?
A couple of notes:
cc. @mariofusco
I'm fine with antlr if @andreaTP is. Keep in mind that WAT is basically just s-expressions (with some caveats) so the parser really should be the easier part if you want to just do it by hand. But if Antlr gives us a better experience that sounds good to me too.
One thing I do want to note as a possible conflict is https://github.com/dylibso/chicory/pull/208 as we're kind of refactoring some of the core wasm encoder and decoder layer. It might not be a problem, but maybe something we should talk about in the team meeting tomorrow.
@andreaTP @bhelx I will come up with a proposal soon. I will attach Screenshots of what is working best after going through a trial and error approach Thanks a lot for your guidance :)
Note that ANTLR generated code depends on antlr4-runtime
which has a strong dependency on the ANTLR generator version, so you would probably want to shade it.
After the merge of #328 we have a viable workaround for the lack of this implementation. Having a native parser is still a goal but priority is decreased.
After the merge of #328 we have a viable workaround for the lack of this implementation. Having a native parser is still a goal but priority is decreased.
That's a brilliant approach
The task is to construct a Parser which converts Text format WASM Module and Generating output through AST using Domain classes already available in the project. ANTLR is a suggested Parsing framework for the task.