Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
rom1504 opened this issue May 20, 2020 · 3 comments

Comments

@rom1504
Copy link
Member

rom1504 commented May 20, 2020

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
Copy link
Member Author

rom1504 commented May 20, 2020

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

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
Copy link
Collaborator

roblabla commented May 20, 2020

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
Copy link
Member Author

rom1504 commented May 20, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants