haXe as git-like toolset

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

haXe as git-like toolset

danielku15
Hi everybody.

I just saw the new haxejs.org site of Joshua and I like this approach to promote single haXe targets.

Thinking about this I got flash of inspiration. What if haXe would be more like the git toolset.

An example: If you call "git clone" the git.exe simply calls git-clone.exe which contains all the encapsulated logic for this task.

Let's translate this approach to haXe: You call "haXe js" and the haXe.exe calls haXe-js.exe

But that's only how the user interacts with haXe, there's a lot more behind this idea. What's the current state? Currently the whole haXe compiler is a combination of the compiler front-, middle- and back-end (in means of compiler theory). haXe has multiple back-ends known as "targets" which are suitable for code-generation. The compiler has a lot of switches like determining the compiler arguments or checking for supported stuff in the front- and middle-end.

It's "hard" for developers to implement new compiler targets. They have to view in several files for target stuff and add their code to it.

The workflow of the compiler is basically (correct me if I'm wrong):
 - call the compiler with all arguments
 - read the compiler arguments
 - determine the target language using ifs/switches
 - do the front-end (lexing, parsing) and middle-end stuff (optimization)
 - delegate the created context object to the target/code generator (back-end) and let it do it's work

This architecture is bad (in my opinion) because this way the core-system has a strong dependency on more concrete implementations.
 
Let's invert this approach to a more flexible/modular architecture:

There's a main compiler framework which does the front- and middle-end stuff of the compiler (lexing, parsing, optimization) This compiler framework can be used by targets. I will call this module the "haXe-core" for know on.

A target, let' take JavaScript, needs to setup a context object which will gets passed to the haXe-core. This context contains stuff like:
 - The name of the target ("JavaScript")
 - The id of the target ("js") - will be used for conditional compiling
 - Path to core-haxe-library including the target specific library (the haXe files)

Now how's the new workflow:
 - you call "haxe js"
 - haxe.exe calls "haxe-js" (simple dispatching)
 - haxe-js.exe loads the haxe-core.dll
 - parse the arguments using argument definitions. (core-arguments are read by the core system, lang-arguments are read by the target system)
 - the haxe-js fills the context object and bypasses the context object to the core-module.
 - the core module does the front-end and back-end stuff
 - the haxe-js gets the result context which contains all the information like errors and the loaded model/ast
 - know the haxe-js system can do what it likes with the model. generate according js-code or run it using a interpreter/vm

This architecture would make haXe a lot more flexible and more suitable for end-users and developers.

Pros:
- Create smaller compiler packages which only create specific targets (like haxe-js only for haxejs.org)
- Make it easier for developers to create haXe targets and experiments. A developer can focus on his target without the fear of destroying any other targets. If a developer implements a new target today and tomorrow you commit a lot of changes to the repository a huge list of conflicts appear and merging those is a painful job. With this new architecture the developer simply replaces the haxe-core and benefit of new stuff without getting his work destroyed.
- Easier maintenance because all modules/targets are separated and independent.
- Easier contribution by the community: They don't need to know all details about the core-system to contribute to a single target.
- Flexible update system: update only haxe-js if there are changes in the javascript module.

Cons:
- A lot of refactoring needed
- The current system works, there's so >need< for change.  


I don't want to "diss" haXe and tell it's written bad. haXe is simply awesome but it has grown over time and I think there are some lacks of this progress. In my opinion such an architecture would make haXe a lot better and cleaner.

The discussion is opened :D

Greetings
Daniel
Reply | Threaded
Open this post in threaded view
|

Re: haXe as git-like toolset

Nicolas Cannasse
Le 13/10/2011 21:56, danielku15 a écrit :
> Hi everybody.
>
> I just saw the new haxejs.org site of Joshua and I like this approach to
> promote single haXe targets.
>
> Thinking about this I got flash of inspiration. What if haXe would be more
> like the git toolset.

The compiler architecture is already very modular.
You can read details here http://haxe.org/doc/advanced/code_generators

Basically, adding a new target require you to add your target parameter
to "main.ml" which is where the commandline arguments for haxe.exe are
handled, and then simply implement your code generator in you own genXXXX.ml

Each generator is perfectly independent from the others. All you have to
do is to keep up with the (quite rare) changes that are done to the haXe
typed AST which represent the "final" representation of a haXe program
before it gets generated to a given platform.

I don't see how we could get more modular than that, especially if we
want to have one single language and not one variant of the language per
platform.

Best,
Nicolas


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: haXe as git-like toolset

Yanis Benson

Another point is that we'll lose speed on exporting core to dll, because we'll need to care about intermediate data format, and lose ocaml optimizations. I doubt anyone will be ok with losing speed, let's leave that to Java guys. And after all, there is no actual benefits at all.

Daniel, as far as I understand, one of your points is that developers should be free from another targets developing for one. Actually, I believe that will already be a big problem in the nearest feature. We get more and more target specific libs instead of having universal ones, and that disrupts initial idea of "one code to rule them all, one code to find them, one code to bring them all and in they haXe file bind them in the land of HaXers where the logic lies". Of course, haXe is a way to go when you just deal with freaky targets like Js or PHP (though many targets can benefit from haXe usage, as it is one of the simplest languages around, on the line with asm and probably C, but together with it's expressiveness it beats everything I guess), but the real treasure lies exactly there, in reusing code.

On 14 Oct 2011 00:23, "Nicolas Cannasse" <[hidden email]> wrote:
Le 13/10/2011 21:56, danielku15 a écrit :
Hi everybody.

I just saw the new haxejs.org site of Joshua and I like this approach to
promote single haXe targets.

Thinking about this I got flash of inspiration. What if haXe would be more
like the git toolset.

The compiler architecture is already very modular.
You can read details here http://haxe.org/doc/advanced/code_generators

Basically, adding a new target require you to add your target parameter to "main.ml" which is where the commandline arguments for haxe.exe are handled, and then simply implement your code generator in you own genXXXX.ml

Each generator is perfectly independent from the others. All you have to do is to keep up with the (quite rare) changes that are done to the haXe typed AST which represent the "final" representation of a haXe program before it gets generated to a given platform.

I don't see how we could get more modular than that, especially if we want to have one single language and not one variant of the language per platform.

Best,
Nicolas


--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org