Text format support for a Java WebAssembly runtime

[kanha-gupta]

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.

[kanha-gupta]

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 ?

[andreaTP]

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:

• the Parser is not supposed to "generate output" but rather create a valid instance of a Module.
• I suggested ANTLR because the generated code doesn't have dependencies and that's something we value in this project

cc. @mariofusco

[bhelx]

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 #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.

[kanha-gupta]

@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 :)

[electrum]

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.

[andreaTP]

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.

[kanha-gupta]

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