-
Notifications
You must be signed in to change notification settings - Fork 18
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
Comments
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 :
|
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. |
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. |
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.
The text was updated successfully, but these errors were encountered: