Try reusing the IIFE compiling concept to produce a protodef compiler for another language

[rom1504]

The new protodef compiler is really simple and short.
Could it be expanded to produce another language ?

This might be quite interesting to help people at wiki.vg not reimplement the protocol 10 times, and expand usage of protodef.

[rom1504]

just to say I'm not forgetting what has been done before. Advantage of this approach over previous stuff :

• https://github.com/ProtoDef-io/elixir-protodef is interesting but really complex, not easy to reuse it to implement a new language
• https://github.com/ProtoDef-io/protodefc is very cool but also complex and it handles a completely new language that is not really declarative, and harder to parse, also we don't have all protocol version with this format, and we don't know if it can produce fast code
• https://github.com/Johni0702/ProtocolGen is interesting but highly java-like OOP with many many classes, I'm not sure if it's needed to be that close to the language to produce an implementation that is useful (also it's not maintained and not very generic)
• there was an haskell compiler, but looks like the repo is gone

what I think would be cool in a new compiler for other languages :

• producing code similar to what an human might write (I think iife kind of fit this)
• simple, should take a few hundred lines maximum
• produced code should be fast
• use json protodef language
• does not have to produce code that is idiomatic for the language, producing dictionaries using IIFE is good

[roblabla]

A big part of what made the other compiler implementations more complex is that they support more than one language. For instance, in protodefc, custom datatype implementations generate an AST that is then lowered by the backend. This has the advantage that adding a custom datatype only needs to be done once (to generate the AST) to be used in every language supported by protodefc.

In contrast, node-protodef compiler directly generates javascript code for custom datatypes that are parametrizable. This means that if we add another language, we need to rewrite every datatype definitions. This would quickly cause gigantic code duplication.

That's not, per se, a bad thing. I think this compiler is great because of how simple it is, which should make hacking on protodef very easy. But if we want to support more languages, we'll want to think of a simple AST that would then be turned by the language backend.

[rom1504]

Yeah it's true it's a part of protodefc complexity, but I think what makes it significantly more complex is it tries (and succeed) to inline everything. I think the IIFE approach make it possible to have an output that is closer to the input, and to have a more simple compiler.

I agree it would be cool to have an intermediate phase instead of duplicating everything in all languages, if it's possible to do that without increasing the complexity too much it would be nice.