Why is the HaXe compiler still in OCAML?

[Skyler Parr]

I completely understand why HaXe was originally written in OCAML, but why is it still written in OCAML?

Bear with me here.  Now that we have a binary that can compile haxe code, why shouldn't the compiler be written in haxe.  There is a lot of good stuff that can happen here.  For one, it's eating our own dogfood.  How great is it that the language itself is written in it's own language?  Plus, there are is a growing force of talented haxe developers, we can leverage all of these haxe developers to make bug fixes and propose features with actual pull requests without having to learn another language. Lastly, if the compiler is written in haxe, the compiler itself suddenly become very portable.  

Imagine with me for a moment:

haxelib install haxecompiler

That would give us the lib for the entire compiler.  Then we could just target any platform (assuming we already have a haxe binary):

haxe -lib haxecompiler -main MyCompiler -js haxe.js

Now we have the compiler for JS.  Then we drop that anywhere that has node:

node haxe.js -main MyProject -cpp MyProject.out

Suddenly we can compile on all sorts of platforms.  Imagine we had a ruby and python target:

haxe -lib haxecompiler -main MyCompiler -ruby haxe.rb

ruby haxe.rb -main MyProject -python myproject.py

Yeah, I just created a compiler for ruby, and used the ruby compiler to generate my project in python. That is power!

I can drop that haxe.rb compiler script onto my smart phone with a ruby interpreter and boom and I can start writing haxe on my phone:

ruby haxe.rb -main MyProjectOnMyPhone -ruby my_proj.rb

ruby my_proj.rb

Am I the only one that sees the possibilities here?

[Luca]

Because ocaml allows the compiler to be very, very fast. It's a great language for writing compilers in. The compiler would be more verbose, and not as fast if written in Haxe and compiled to any of the current haxe targets.

[Joshua Granick]

It is still a valid point, though, of "dog fooding" the language. If OCAML is faster than Haxe for a compiler, could Haxe be made faster? Would this require access to more "fundamental" data types?

[Raoul Duke]

for most programming languages that don't have a polyglot back-end, it
would not be so good a question, given ocaml's prowess in the compiler
arena.

but for haxe it makes more sense to me. what if -- ha ha -- haxe had
an ocaml back-end ;-)

(take a look at, for example, qi/shen lisp, which started off
compiling down to lisp (but making really fast executables vs. the
best human lisp hackers) and which now can compile to many different
languages. similar arguments there for compiling it in itself
somehow.)

> --
> To post to this group haxe...@googlegroups.com
> http://groups.google.com/group/haxelang?hl=en
> ---You received this message because you are subscribed to the Google Groups
> "Haxe" group.
> For more options, visit https://groups.google.com/groups/opt_out.

[Skyler Parr]

If speed is the "main" reason to have it implemented in OCAML, then having an OCAML target would be ideal.  But, I would trade speed for portability in this case.  A cross platform compiler, not just a cross platform language.

[Dan Korostelev]

I wonder. Now that haxe has very powerful pattern matching that is really useful for working with AST, speed is probably the only obstacle besides the amout of effort of porting ocaml code :) I think porting Haxe to Haxe could make sense when the C target becomes a thing.

понедельник, 27 января 2014 г., 21:43:50 UTC+4 пользователь Skyler Parr написал:

[Simon Krajewski]

Am 27.01.2014 20:32, schrieb Dan Korostelev:
> I wonder. Now that haxe has very powerful pattern matching that is
> really useful for working with AST, speed is probably the only
> obstacle besides the amout of effort of porting ocaml code :) I think
> porting Haxe to Haxe could make sense when the C target becomes a thing.

The problem Haxe has is that it has to consider Dynamic in many places.
It would require a good static analyzer to find regions of code which
can be optimized.

However, even then it's a stretch to think we could compete with OCaml,
a language which was clearly designed with writing compilers in mind.
They are ahead in both years of development and amount of ambitious
Frenchmen.

Simon

[Saar Korren]

I do feel there are various areas in which HaXe's output is sub-optimal.

The syntax and meta-programming, though, make it easy to hand-write lexers and AST parsers. The macro system can replace the job of compiler-compiler. So I disagree with regards to code verbosity.

On speed, I do feel like some of the targets should be more optimized, and perhaps reliance on Dynamic in the standard library should be reduced.

[Marc Weber]

I'm pretty sure that I would finds posts by me about this topic, too.
Its likely that people joining haxe will ask such question one day.

There are many small reasons, eg ocaml supports match x with
A|B -> thing

whereas haxe only supports
A -> thing
B -> thing

If you really try to implement a parser in haxe (even a simple json
parser) you might understand the difference.

(I'm not saying the ocaml implementation is perfect, its quite low
level, too)

But if we talk about such a change (which would benefit the community in
many ways, because you could have IDE in browser only etc) .. some
additional changes should be considered - and then this topic might turn
into "rewrite - and what to include" ..

While haxe is general purpose I'm unsure whether its general purpose
enough for all tasks - eg such as maintaining "big data" in memory etc.

In a perfect world I would have such a language..
And just using boehmgc would eventually not be strong enough, unless you
tell boehmgc about details where pointers may happen and where not.

In big data case it might even make sense to allow multiple memory
management types in the same application..
And then we get into areas like region typing like dcc:
http://disciple.ouroborus.net/
Suddenly you start having a big change and increase in complexity
eventually.

Also the typer could be little stronger in some ways in some corner
cases etc.

module FOO

function bar(){
INJECT_POINT_C

switch (x) {
case "abc":
INJECT_POINT_D
}
}


so that you could write additional modules adding code like this:
my-extension:

FOO:INJECT_POINT_C
trace("my extension is tracing");

FOO:INJECT_POINT_D
case "C":
trace("hit case C")

There are much more unsolved issues such as cross platform mysql support
for nodejs and the other targets and so on (But I don't know how the
perfect solution would look like yet)..

I've started a personal list of features I'd like to have. When I'm done
I'll start thinking about how much effort it would be to implement such.
(Maybe I'll never get to that state).

Those are just some simple thoughts not trying to be complete.

Marc Weber

[Simon Krajewski]

Am 28.01.2014 10:22, schrieb Marc Weber:
> I'm pretty sure that I would finds posts by me about this topic, too.
> Its likely that people joining haxe will ask such question one day.
>
> There are many small reasons, eg ocaml supports match x with
> A|B -> thing
>
> whereas haxe only supports
> A -> thing
> B -> thing
>
> If you really try to implement a parser in haxe (even a simple json
> parser) you might understand the difference.

That's not true, Haxe has supported or-patterns since 3.0. I've written
a basic JSON parser as test for hxparse:
https://github.com/Simn/hxparse/blob/master/test/JSONParser.hx

Simon

[Marc Weber]

What about having lib.haxe.org send updates once a month the
mailinglist? (Something short like the lib.haxe.org frontpage shows)

Its quite easy to miss important ideas/implementations like
yours ..

Marc Weber

[Saar Korren]

Most of the things described, if I understand them correctly, can be done using macros. If you're talking about the AST parsing phase, this can DEFINITELY be done in HaXe. I haven't checked JSON, but I did make a partial parser for PHP. Using macros, you can build something that works like yacc or javacc, generating standard parsing code.

Generating AST is the easy part. I could probably write it in a weekend. Or at least I could, if HaXe's syntax was somewhat better documented (EBNF specs plz).

It's the part that comes after that is difficult: Macro execution, type inference, and code generation.

[Simon Krajewski]

Am 28.01.2014 13:59, schrieb Saar Korren:
> Most of the things described, if I understand them correctly, can be
> done using macros. If you're talking about the AST parsing phase, this
> can DEFINITELY be done in HaXe. I haven't checked JSON, but I did make
> a partial parser for PHP. Using macros, you can build something that
> works like yacc or javacc, generating standard parsing code.
>
> Generating AST is the easy part. I could probably write it in a
> weekend. Or at least I could, if HaXe's syntax was somewhat better
> documented (EBNF specs plz).

I've made a haxe parser for hxparse too:
https://github.com/Simn/hxparse/blob/development/test/HaxeParser.hx

There are some things missing (conditional compilation is ignored, macro
reification isn't implemented and regex literals are not lexed). I've
used it to make a basic REPL, which is pretty much a port of the macro
evaluation loop: http://simn.de/haxe/repl/

Simon

[Saar Korren]

When you say "macro reification isn't implemented", do you mean it doesn't produce the matching AST output, or that it throws a syntax error?

Anyway, it seems like a good start for a HaXe-based compiler. Especially considering you have the macro evaluation loop ported.

If you can make it produce some sort of fully-typed intermediate code, it would be simple enough to plug code generators as a layer on top of that.

[Simon Krajewski]

That's all nice and correct, but the point still stands that it would be
abysmally slow compared to the real compiler.

Simon

[Saar Korren]

Why so? Is the code sub-optimal in some significant way?

[Marc Weber]

Excerpts from Saar Korren's message of Tue Jan 28 18:10:20 +0100 2014:

> Why so? Is the code sub-optimal in some significant way?

Because haxe uses dynamic hash like things for all structures even when
compiling to c for instance. Even using

x = {x: 7, y:8};
gets translated to to something like this internally:
x = new Hash()
x.set(x, 7)
x.set(y, 8)
(look at the generated C code).

In ocaml I guess that such get compiled down to struct like stuff,
thus:
x = alloc(12 bytes)
x.x=7;
x.y=9;

Of course other people will know much better than I do (again) :)

Marc Weber

[Raoul Duke]

> x = alloc(12 bytes)

no, no, it is 13 bytes. sheesh!

(:-))

[Luca]

On Tuesday, January 28, 2014 6:47:52 PM UTC, MarcWeber wrote:

compiling to c for instance. Even using

(look at the generated C code).

Haxe doesn't compile to C... yet (genc branch). And when it's completed, this will hopefully not be the case as it is for the c++ target 

[Saar Korren]

I actually made a thread dedicated to complaining about this issue. And opened an issue in github. Hugh mostly answered that it is outside of the current scope of development, and closed the issue.

But this is not always the case. While all objects allow full string-based reflection, not all uses demand it. If you avoid certain features, like anonymous objects, for instance, you can still produce relatively efficient code.

Also, a multi-layered HaXe-based compiler would make it easier to write more effective code generators. It's not an issue of the language, but one of the implementation.

[Juraj Kirchheim]

On Tue, Jan 28, 2014 at 7:47 PM, Marc Weber <marco-...@gmx.de> wrote:
> Excerpts from Saar Korren's message of Tue Jan 28 18:10:20 +0100 2014:
>> Why so? Is the code sub-optimal in some significant way?
>
> Because haxe uses dynamic hash like things for all structures even when
> compiling to c for instance.

FYI: the haxe/java backend doesn't have this shortcoming.

[Juraj Kirchheim]

On Tue, Jan 28, 2014 at 11:07 PM, Saar Korren <slugf...@gmail.com> wrote:
> I actually made a thread dedicated to complaining about this issue. And
> opened an issue in github. Hugh mostly answered that it is outside of the
> current scope of development, and closed the issue.
>
> But this is not always the case. While all objects allow full string-based
> reflection, not all uses demand it. If you avoid certain features, like
> anonymous objects, for instance, you can still produce relatively efficient
> code.

Let's be clear on this one: Ad-hoc class generation is relatively
tricky and Hugh doesn't feel it's worth the effort.
And no, you cannot simply not use anonymous types in Haxe, since
Iterator and Iterable are anonymous types.
Porting this from genjava to gencpp should be feasible for someone who
has the necessary knowledge of C++ and OCaml - which disqualifies me
twice :D

> Also, a multi-layered HaXe-based compiler would make it easier to write more
> effective code generators. It's not an issue of the language, but one of the
> implementation.

I'm not sure what you mean by that. The generators are all in a
separate layer and you can add one if you wish to. You can even plug
in a Haxe based generator if you want to:
http://api.haxe.org/haxe/macro/Compiler.html#setCustomJSGenerator

[Juraj Kirchheim]

I have some doubts regarding that.

Firstly, if you compile the compiler to a platform where dynamic code
loading is straightforward, macro execution (as well as passing data
between the compiler and macros) could become orders of magnitude
faster. So depending on how macro heavy the project is, one might even
be able to outperform the current compiler, maybe even when it's
running on JS (at least for an incremental compilation).

Secondly, I do think that if ported to Haxe to be compiled on a
haxe/ocaml backend, there's no inherent reason for it to be
significantly slower. I think enums should be mappable onto OCamls
ADTs and anonymous types should be mappable to structs (along the
lines of how haxe/java maps them to classes) and OCaml tuples could be
ported to become anonymous types. If you use boxing to promote values
to Dynamic or EnumValue, and simply don't use them in the port, I
don't think there should be any overhead involved.
Along those lines, I think a C backend that manages to use structs and
unions for enums and anonymous objects should also perform rather
well.

I am well aware that this is easier said than done. But I would be
curious to understand why you believe that it cannot be done at all
(*it* meaning to achieve performance roughly in the same ballpark).

Regards,
Juraj

[Simon Krajewski]

Well, I was obviously talking about our current targets and not some
hypothetical future target from space.

But even for that you would have to offset Haxe's inherent
performance-detrimental specification with a really good static
analyzer. I'm not even sure if anyone in this community has the skill,
let alone the time for that. I'm not saying it's impossible, it's just
unrealistic.

Simon

[Saar Korren]

Last I checked, the Java output suffers from the same issues as the CPP one, minus the reflection add-ons (Since Java has built-in reflections)

Your point on needing to know OCaml to add something to the CPP target is valid, and is precisely what I was trying to point out. I do know a fair amount of CPP, but would have to learn to use OCaml through-and-through before I can consider touching HaXe's code generators. Being a separate module in OCaml doesn't really help HaXe developers add new generators.

I looked at the setCustomJSGenerator API you sent, and while I don't fully understand how it works and what it does, I can see that it's not the appropriate API for a custom generator. It calls code generation incrementally, per-object, instead of passing some partially-compiled complete class-structure. If anything, the OnGenerate callback gets something that is closer to the right input for a code generator.

So while an argument that current generators won't produce a fast compiler are valid, they only serve as an argument in favor of a HaXe-based compiler, because it would be easier to write superior generators in HaXe, and then use them to compile a better compiler.

[Nicolas Cannasse]

Le 29/01/2014 12:06, Juraj Kirchheim a écrit :
> On Tue, Jan 28, 2014 at 11:07 PM, Saar Korren <slugf...@gmail.com> wrote:
>> I actually made a thread dedicated to complaining about this issue. And
>> opened an issue in github. Hugh mostly answered that it is outside of the
>> current scope of development, and closed the issue.
>>
>> But this is not always the case. While all objects allow full string-based
>> reflection, not all uses demand it. If you avoid certain features, like
>> anonymous objects, for instance, you can still produce relatively efficient
>> code.
>
> Let's be clear on this one: Ad-hoc class generation is relatively
> tricky and Hugh doesn't feel it's worth the effort.

We could support it at some point the compiler by having:

@:class typedef X = {
...
}

And replace that with a proper class definition + allow initialization
from a constant structure. However that would impact the typing by not
allowing anymore structural subtyping.

Best,
Nicolas

[Nicolas Cannasse]

> Secondly, I do think that if ported to Haxe to be compiled on a
> haxe/ocaml backend, there's no inherent reason for it to be
> significantly slower. I think enums should be mappable onto OCamls
> ADTs and anonymous types should be mappable to structs (along the
> lines of how haxe/java maps them to classes) and OCaml tuples could be
> ported to become anonymous types. If you use boxing to promote values
> to Dynamic or EnumValue, and simply don't use them in the port, I
> don't think there should be any overhead involved.

That wouldn't work as soon as you start having some kind of Reflection,
or that would require some smart Dynamic type that carry both the value
and the original type with it. Not that much straightforward.

Anyway, as Simon said, we have no plans atm to have the Haxe compiler
being rewritten in Haxe. In order to be efficient this would definitely
require an Haxe/OCaml backend which has a very efficient GC which is one
of the reason of the compiler speed. If someone volunteer to write such
backend we would surely be pleased to have it. Otherwise it's just
"what-if" talks.

Best,
Nicolas

[Nicolas Cannasse]

Le 29/01/2014 14:27, Saar Korren a écrit :
> Last I checked, the Java output suffers from the same issues as the CPP
> one, minus the reflection add-ons (Since Java has built-in reflections)
>
> Your point on needing to know OCaml to add something to the CPP target
> is valid, and is precisely what I was trying to point out. I do know a
> fair amount of CPP, but would have to learn to use OCaml
> through-and-through before I can consider touching HaXe's code
> generators. Being a separate module in OCaml doesn't really help HaXe
> developers add new generators.

Anyone that feels qualified enough to deal with a compiler should also
be to learn the minimum of OCaml required for the task.

New generators can already be experimented written in pure Haxe code by
using macros, as the python generator shows.

Best,
Nicolas

[Saar Korren]

I have to disagree. Learning OCaml isn't like learning a new algorithm, or data structure, or another imperative language (e.g. Basic, Pascal, Python). It's a different programming paradigm altogether. I've worked with ML in the past, and have found even the most simple tasks to be incredibly hard to pull off. And this is before you consider the sheer amount of dependencies required to actually build the compiler from the OCaml code. If it was written in, for example, C, it would still be much easier to work with.

Also, what Python generator? There's no mention of one in the HaXe documentation, and Google comes up blank. A link would be nice.

Speaking of things that would be nice, some official language specs would go a long way. EBNF for the syntax would be a good start. And maybe a more thorough explanation of how the macro system works, and which standard libraries and features are accessible while it runs. And also, how "#if macro" works, that one really baffles me. Because, right now, the way I see it, a major obstacle to making another compiler, is figuring out how to make it 100% compatible with the existing one.

[Simon Krajewski]

Am 29.01.2014 16:59, schrieb Saar Korren:

I have to disagree. Learning OCaml isn't like learning a new algorithm, or data structure, or another imperative language (e.g. Basic, Pascal, Python). It's a different programming paradigm altogether. I've worked with ML in the past, and have found even the most simple tasks to be incredibly hard to pull off. And this is before you consider the sheer amount of dependencies required to actually build the compiler from the OCaml code. If it was written in, for example, C, it would still be much easier to work with.

You should really try to adjust yourself to the status quo here instead of wishing it was something you're more accustomed to. The Haxe repository comes with its dependencies, about the only thing you have to install is OCaml. What OS are you on?

Also, what Python generator? There's no mention of one in the HaXe documentation, and Google comes up blank. A link would be nice.

https://github.com/frabbit/hx2python

Speaking of things that would be nice, some official language specs would go a long way. EBNF for the syntax would be a good start. And maybe a more thorough explanation of how the macro system works, and which standard libraries and features are accessible while it runs. And also, how "#if macro" works, that one really baffles me. Because, right now, the way I see it, a major obstacle to making another compiler, is figuring out how to make it 100% compatible with the existing one.

Writing EBNF is quite some work which I don't think anyone would pay us for, making it a really ungrateful task with dubious advantages. I suggest you take a look at the parser implementation (https://github.com/HaxeFoundation/haxe/blob/development/parser.ml), which despite being OCaml should give you a good idea of the syntax.

I'm trying to put the macro system into context in the new manual, but it's quite hard to find the optimal level of detail for this kind of documentation. Still, you can read through https://github.com/HaxeFoundation/HaxeManual/blob/master/md/manual/macro.md and take a look at http://simn.de/haxe/haxemacro2.png

`#if ident` checks if "ident" is defined (explicitly from command line via -D ident or as part of the compiler like in the case of "macro") and discards all tokens until the next #else, #elseif or #else if it isn't. This is also described here: https://github.com/HaxeFoundation/HaxeManual/blob/master/md/manual/lf-condition-compilation.md

Simon

On Wednesday, January 29, 2014 4:27:49 PM UTC+2, Nicolas Cannasse wrote:

Le 29/01/2014 14:27, Saar Korren a écrit :
> Last I checked, the Java output suffers from the same issues as the CPP
> one, minus the reflection add-ons (Since Java has built-in reflections)
>
> Your point on needing to know OCaml to add something to the CPP target
> is valid, and is precisely what I was trying to point out. I do know a
> fair amount of CPP, but would have to learn to use OCaml
> through-and-through before I can consider touching HaXe's code
> generators. Being a separate module in OCaml doesn't really help HaXe
> developers add new generators.

Anyone that feels qualified enough to deal with a compiler should also
be to learn the minimum of OCaml required for the task.

New generators can already be experimented written in pure Haxe code by
using macros, as the python generator shows.

Best,
Nicolas

--

[Marc Weber]

Excerpts from Saar Korren's message of Wed Jan 29 16:59:41 +0100 2014:

> hard to pull off. And this is before you consider the sheer amount of
> dependencies required to actually build the compiler from the OCaml code.

This has been fixed (by me multiple times). Just nobody was interested
in adopting a rewrite of the makefile..

https://github.com/MarcWeber/haxe/blob/export/rake-conditional-compilation/makefile-generated-by-rake
This makefile will checkout everything required only assuming you have
"ocaml" in PATH.

But even without that its quite easy, just the support libraries and
build the main thing..

> If it was written in, for example, C, it would still be much easier to work
> with.

No, because C is harder to work with.
In the end ocaml is little bit of both: functional and imerpative.
If you want to updaet in place you have to declare it.
Other than that Exceptions are used often.

The match thing with
A | ...
is much nicer than ints in C, sry.

If you need getting started with compiling haxe I'll help you ..

> Speaking of things that would be nice, some official language specs would
> go a long way. EBNF for the syntax would be a good start.

the parser contains some tweaks to cope with invalid files so that
completion can be done ..

> macro" works, that one really baffles me. Because, right now, the way I see
> it, a major obstacle to making another compiler, is figuring out how to
> make it 100% compatible with the existing one.

:) Even the "existing one" is changing a little bit - I mean bugs get
fixed etc.

Marc Weber

[Stephane Le Dorze]

Nobody with enough experience in with C and ML would seriously consider C as a more practical language than an ML derivative to write a compiler, and this, exactly because of the paradigm is emphasis.

I would argue that learning Ocaml is easier than the amount of knowledge to write a compiler, even *correctly* implementing unification within the typer.

[Saar Korren]

I know what "#if cpp" or "#if js" do. That much is obvious for anyone with even limited C/C++ experience. But what does "#if macro" do? Does HaXe produce separate ASTs for the macro system and the regular code generation? And how are they merged while the macro is running?

I've also been experimenting with the syntax, and finding some oddities. For instance, the following program:

class TestMain
{
    macro static function mymacro()
    {
        var a = [macro 1];
        var c = "2";
        trace(macro $c{a});
        trace($c{a});
        return macro {};
    }

    static function main()
    {
        mymacro();
    }
}

builds successfully, and outputs, during the compilation (Positions trimmed for brevity):

{ expr => EMeta({ name => 2, params => [], pos => #pos(...) },{ expr => EConst(CIdent(a)), pos => #pos(...) }), pos => #pos(...) }
[{ expr => EConst(CInt(1)), pos => #pos(...) }]

I mean... What? I don't even...

[Andreas Mokros]

Hi.

On Wed, 29 Jan 2014 14:36:11 -0800 (PST)
Saar Korren <slugf...@gmail.com> wrote:
> But what does "#if macro" do? Does HaXe
> produce separate ASTs for the macro system and the regular code
> generation? And how are they merged while the macro is running?

Did you read this (and the following pages)?
https://github.com/HaxeFoundation/HaxeManual/blob/master/md/manual/macro.md

--
Mockey

[Simon Krajewski]

That's an implementation detail which only surfaces if you use undefined dollar prefixes like `$c{e}`. The parser translates this to `@:c e` in order to easily encode the information into the AST. During reification this is then picked up and handled depending on the prefix, but with "c" not being defined the metadata is passed through and you end up with `@2 a`.

Simon

[Saar Korren]

 I have, and it doesn't answer my question. It doesn't even come close to answering my question. It doesn't even produce a useful hint.

[Nicolas Cannasse]

Le 30/01/2014 05:46, Hugh a écrit :
> I have said I would support adding performance features to get a
> haxe-haxe compiler working in cpp.
>
> There are many phases to compiling - lexing, parsing,
> transforming/macros, typing, backend.
>
> The lexing/parsing can be done efficiently in hxcpp if you take care
> with performance in mind. I did some measurements a while ago, and code
> from:
>
> http://code.google.com/p/hxbison/source/browse/trunk/bison/LexerBase.hx
>
> lexed/parsed about as fast as haxe. This was also when "inline static"
> was like "#define" and char constants were not ints. The key is to not
> "substr" the chars into strings if you do not need to. So this is not
> as pretty as a some generic solution, but to most haxe users it is
> prettier than ocaml, since ocaml can be impenetrable.
>
> They "typing" phase may or may not be slower, but it could be made
> multi-threaded, so potentially it could be an order of magnitude faster
> than a single-threaded ocaml version.

Typing with type inference is very hard to parallelize, or else we would
have done it already (OCaml has threads).

I have solid experience in writing optimized C code and I can say that
Ocaml compiler is definitely faster when it comes to manipulating a lot
of memory, thanks to its fast generational GC. And the Haxe compiler
does a lot of map's.

It's not that I'm that much an Ocaml fan : it has poor tooling and is
not very known. But so far the benefits outweigh the drawbacks, not
mentioning the time it would take to rewrite the whole compiler and the
bugs that would get introduced while doing it.

Best,
Nicolas

[Boyan O]

This idea may sound very exciting, but it's pretty not easy to achieve. And actually only makes sense for js target.

понедельник, 27 января 2014 г., 19:43:50 UTC+2 пользователь Skyler Parr написал:

I completely understand why HaXe was originally written in OCAML, but why is it still written in OCAML?

Bear with me here.  Now that we have a binary that can compile haxe code, why shouldn't the compiler be written in haxe.  There is a lot of good stuff that can happen here.  For one, it's eating our own dogfood.  How great is it that the language itself is written in it's own language?  Plus, there are is a growing force of talented haxe developers, we can leverage all of these haxe developers to make bug fixes and propose features with actual pull requests without having to learn another language. Lastly, if the compiler is written in haxe, the compiler itself suddenly become very portable.  

Imagine with me for a moment:

haxelib install haxecompiler

That would give us the lib for the entire compiler.  Then we could just target any platform (assuming we already have a haxe binary):

haxe -lib haxecompiler -main MyCompiler -js haxe.js

Now we have the compiler for JS.  Then we drop that anywhere that has node:

node haxe.js -main MyProject -cpp MyProject.out

Suddenly we can compile on all sorts of platforms.  Imagine we had a ruby and python target:

haxe -lib haxecompiler -main MyCompiler -ruby haxe.rb

ruby haxe.rb -main MyProject -python myproject.py

Yeah, I just created a compiler for ruby, and used the ruby compiler to generate my project in python. That is power!

I can drop that haxe.rb compiler script onto my smart phone with a ruby interpreter and boom and I can start writing haxe on my phone:

ruby haxe.rb -main MyProjectOnMyPhone -ruby my_proj.rb

ruby my_proj.rb

Am I the only one that sees the possibilities here?