I have a proposal.
I’m putting this out here, before going any other route, because… well, maybe it’s a silly proposal; maybe it cannot be done because x, y and z; maybe it has been tried before but failed because reasons…
Anyway, here it is:
Proposal: Allow Haxe targets to be implemented as plugins, in the form of executables / servers.
I propose a system whereby it should be possible to implement a new Haxe target backend, not (necessarily) in OCaml, but as an executable that can be implemented in any language capable of creating standalone executables that work on the platform where the haxe executable works (e.g., in Haxe, or in the target language itself). The haxe executable can then run the plugin executable, request any information is needs from it, send back any information the plugin needs, and finally instruct the plugin to generate the output.
Such plugins would have to follow a well-defined pattern:
E.g., on Windows, suppose our haxe.exe is located in C:\HaxeToolkit\haxe\, and we want to implement a (completely hypothetical, of course) COBOL target.
For this purpose, there could be a “targets.json” in the same folder where the haxe executable is located, and it could look something like this:
{
"targets" : {
"COBOL" : {
"enabled" : true, // Haxe compiler will only consider this a valid target if this is set to true.
"switch" : "cbl", // The command line switch (in this case "-cbl" or "--cbl") that tells the
// Haxe compiler to use this target.
// This should also then be a defined compiler directive in haxe code:
//
// #if cbl
// // Only compile this if target is cbl
// doCobolThing(1,2,3);
// #end
//
"generator" : "./targets/cobol/cobol.exe", // The actual target plugin executable / server
},
"Ada" : {
// etc
},
"Fortran" : {
// etc
}
}
}
The Haxe compiler, upon receiving the –cbl switch, should check whether a targets.json exists, then whether the target exists in targets.json, then check whether enabled == true, and then run ./targets/cobol/cobol.exe, as a server.
The plugin should continue running, as a server, until the Haxe compiler terminates it, or the Haxe compiler itself is terminated.
Communication between Haxe compiler and plugin executable would have to follow a strict protocol, much like the Language Server Protocol, in the form of JSON-RPC strings.
I imagine compiler and plugin versions would have to be checked whether mutually compatible (either side can decide it can or cannot handle the other side’s version, and only if they both say yes, then proceed; a bit like Brexit, only smarter, and more productive…), then the Haxe compiler would have to query what kind of target it is:
- Are you a sys target?
- Is your type system static or dynamic?
- Do you support overloaded functions?
- Do you support threading?
Etc.
Finally, when all the negotiating is done, the compiler should send the AST, instruct the plugin to generate the output, and the plugin should report a success or failure result back to the Haxe compiler.
===
Is this something that sounds interesting, feasible, doable, silly…?
Which means that they wouldn’t, and soon enough we would have things wandering this way and that.
which is a big limitation for external targets.