dylibso / chicory

Native JVM WebAssembly runtime
Apache License 2.0
426 stars 34 forks source link

Text format support for a Java WebAssembly runtime #224

Open kanha-gupta opened 7 months ago

kanha-gupta commented 7 months ago

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 commented 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 ?

andreaTP commented 7 months ago

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

bhelx commented 7 months ago

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.

kanha-gupta commented 6 months ago

@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 commented 5 months ago

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 commented 3 months ago

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 commented 3 months ago

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