One of the significant new features of ZPE 1.12.5 is the return of transpilers. ZPE 1.12.3 paved the way for this update, and the performance improvements made have made this possible.
Transpilers have been a part of ZPE since 2015/16, when they were first introduced, but have never got to the stage they are at now. Thanks mainly to the redesign of my ZIP System (or ZPE Internal Plugin System), the rebuild of the internal plugin manager and the move from Eclipse to IntelliJ IDEA, ZPE can now load in plugins again. This means that transpilers, which come in the form of plugins, can now be made again. I've been writing a transpiler from the SQARL to YASS for a while, so I have been planning how to bring this to ZPE for a while now.
Now, with ZPE 1.12.5+, transpilers can be used again.
What the transpilers are
The transpilers allow conversion from the YASS language into another language with minimal effort. I chose Python as the first language to translate because it broadly matches the code structure of YASS. However, Python does lack several features that YASS has, including simple things like constants (what?!), data typing (again, what?!), and even access modifiers (public, private, etc., and again, what?!). I'm unsure why Python misses such simple things, but there we go.
The first transpiler constructed was a Java transpiler. Because ZPE was weakly typed back then, it wasn't possible to decide what data types to assign to each value other than through type inference, so everything was a Java Object. Fast-forward nine years, and the Python transpiler has shown that a weakly typed language like Python is straightforward to implement.
What the transpilers are not
These transpilers act on compiled code. ZPE reads the YASS code, compiles it to the IAST (inlined AST) structure it would be converted prior to execution and then passes it to the transpiler. The transpiler must then break the IAST down and convert it to the destination language. This means that constants from ZPE have already been processed, meaning you cannot expect to see constants in the output program. This will likely never change.
Another thing that will not be kept is commentary. Any comments made are removed from the parsed program before compilation anyway. However, I am considering bringing comments to this at a later stage.
Building transpilers for ZPE
Building transpilers that will run in ZPE is reasonably straightforward. The best way to do this is to look at my Python transpiler on GitHub.
Simply put, a transpiler is expected to:
- Convert code (from an IAST) in a deterministic manner
- Handle imports and libraries required
- Provide polyfills for missing functions considered key to the program
A prominent example is the match statement in YASS. As a polyfill in Python, it converts the match statement to a dictionary and contains a subscript with the value required in the match statement.
