[haxe] what is missing from Haxe to replace Ocaml as a compiler language?

[j...@justinfront.net]

I see the discussion on short Lambda's but really I don't see how a
feature would really effect the fact that Haxe language is already one
of the best languages out there, and certainly one of the most
underestimated and flexible ones.

But still I often wonder why Ocaml is better to code Haxe compiler in,
having done a bit of functional reading I have some understanding. But
the question remains... Haxe seems to excel in so many areas yet it fall
short on the fast LLVM functional language slot, could we change that,
what features would be needed would a new special target along side Neko
be needed... ?

Is there some fundamental reason why Haxe can not address, or will never
be able to address, the Functional LLVM compiler aspect of coding?

When Nicolas originally looked at flash, php, and html and thought lets
just make something simpler and more sensible and not spend life
switching languages what resulted is amazing, but still there seems no
plans to just make Haxe a full on replacement for Haskell, ocaml, f#
etc.. in the way it seems it can currently do with as3, php, java,
javascript c#.

I don't think short lambda's really make any dent in this area of
coding, but what would? What's missing an LLVM target or something more?

[Nicolas Cannasse]

Le 13/09/2014 15:35, j...@justinfront.net a écrit :
> I see the discussion on short Lambda's but really I don't see how a
> feature would really effect the fact that Haxe language is already one
> of the best languages out there, and certainly one of the most
> underestimated and flexible ones.
>
> But still I often wonder why Ocaml is better to code Haxe compiler in,
> having done a bit of functional reading I have some understanding. But
> the question remains... Haxe seems to excel in so many areas yet it fall
> short on the fast LLVM functional language slot, could we change that,
> what features would be needed would a new special target along side Neko
> be needed... ?
>
> Is there some fundamental reason why Haxe can not address, or will never
> be able to address, the Functional LLVM compiler aspect of coding?

A few things that makes OCaml better for compilers :

- a very efficient compiler and garbage collector : even if written in
Haxe, using the OCaml platform as a target would be necessary to reach
the speed of the current compiler

- tuples support, although this could be emulated with macros

- first class immutable lists - with corresponding pattern matching,
which are something we don't have

- currying : Haxe makes it explicit with .bind, it's implicit in OCaml
(but this creates restriction on optional parameters usage).

- structures are not objects, so this would require a specific optimized
way to define structures, this should be doable with abstracts+macros

I might forget a few additional things.

No real show stopper, but it means that would not be an easy task (and
we have also to port the 28K lines of the compiler (+37K lines for the
platform generators), which is not a lot but every small details count here.

It's still possible to write compilers in Haxe - I actually entirely
rewrote the HxSL compiler in Heaps.io with AGAL and GLSL output - but I
still feel that having the Haxe compiler in OCaml is better atm.

Best,
Nicolas

[j...@justinfront.net]

> - a very efficient compiler and garbage collector : even if written in
> Haxe, using the OCaml platform as a target would be necessary to reach
> the speed of the current compiler

Would genC would give you the low level control and potential speed?

> - tuples support, although this could be emulated with macros

like these
https://github.com/deltaluca/goodies/blob/master/goodies/Tuple.hx ?

> - first class immutable lists - with corresponding pattern matching,
> which are something we don't have

So the target would need first class immutable lists or Haxe?

> - currying : Haxe makes it explicit with .bind, it's implicit in OCaml
> (but this creates restriction on optional parameters usage).

Implicit and explicit currying... mmm might have to google that to have
any idea what that means.

> - structures are not objects, so this would require a specific optimized
> way to define structures, this should be doable with abstracts+macros

abstract+macros that sounds scary!

> No real show stopper, but it means that would not be an easy task (and
> we have also to port the 28K lines of the compiler (+37K lines for the
> platform generators), which is not a lot but every small details count
> here.

Did anyone look at the source for http://www.ocamljava.org/

[Hugh]

So it depends on how you would go about re-writing it.

1. Machine translation - in which case the points you make about missing features is quite valid, but the number of lines to port less so.

2. Manual translation, where the number of lines is hugely important, but features could be done entirely differently. eg, I would love to see tuples replaced with structs with names.

And speed - it can be measured.  Haxe opens up some other options, like the ability to multi-thread the lexing of the files and the code-gen, if not the typing 100%.  So I do not think it would be that bad.

There are also a few hybrid options - eg haxe compiler for JS os AS3 can be done using LLVM, c++/neko with a dll.  And the backends could be ported to haxe even if the main compiler is not.

I guess it depends on your goal - including the compiler in other projects (eg, IDE) or writing your own backend can be done with much lower risk using the hybrid techniques.  Messing with the frontend yourself in a language you know - it would be nice to do in haxe.

Hugh

[Nicolas Cannasse]

> And speed - it can be measured. Haxe opens up some other options, like
> the ability to multi-thread the lexing of the files and the code-gen, if
> not the typing 100%. So I do not think it would be that bad.

I've already tried a few times to add multithreading in Haxe compiler
(since Ocaml has threads), but given that most of the time is spent in
typing and because of the dependency between types in the context of
type inference this would be actually quite hard to get right.

Best,
Nicolas

[Simon Krajewski]

Also we should probably fix our existing typing order issues before we
venture into that area. :)

Simon

[David Peek]

In terms of machine translation of the existing codebase, how much effort would be involved in a OCAML to Haxe compiler? At least there's a decent OCAML parser in OCAML already ;)

I suppose the compiler is one thing, but you'd also need to map OCAML std lib to Haxe equivalents, or could you just transpile those two? (I would guess those would have a low level implementation though)

On the flip side, I think developers (myself included) mistakenly assume that OCAML is the thing stopping them from contributing to the compiler. It really isn't. OCAML isn't hard to learn. The barrier to entry is 30,000 lines of highly complex, terse, undocumented compiler code. Compile that to Haxe and all you'll end up with is 60K lines of harder to read, possibly more complex, equally undocumented compiler code.

David

[Cauê Waneck]

2014-09-15 4:41 GMT-03:00 Nicolas Cannasse <ncan...@gmail.com>:

I've already tried a few times to add multithreading in Haxe compiler (since Ocaml has threads), but given that most of the time is spent in typing and because of the dependency between types in the context of type inference this would be actually quite hard to get right.

Actually afaik OCaml threads don't provide parallelism, only concurrency - only one thread may be active at a time. So threading in OCaml won't get us very far, except from being able to do something while another thread is doing I/O.

Best,
Nicolas

--
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/d/optout.

[j...@justinfront.net]

Interesting points. But I don't want the question to be misunderstood,
Haxe has managed to become the ideal language choice for many areas of
coding (if you know and use it, and have the choice), but seems it is
the ultra fast functional language area for compilers and maths code
that is most needing new thought and focus.

Porting Haxe compiler to Haxe and not having a loss in speed or
reliability would be a nice to have and potentially easier for some to
contribute depending on how it was done, but really that sort of a side
point to my question, it's the gaping hole in Haxe armory that I was
asking about.

I am not sure an Ocaml target - would be the ideal solution to this but
maybe it would, maybe it's just an area Haxe should leave to Ocaml or
similar. But I just see the Haxe language discussions bogged down in
short lambda debates when really I don't see this an particularly
relevant in addressing the fast functional language aspect and hoped my
question would raise some ideas about the true failings of Haxe in the
area of ultra fast functional code, surely Haxe is more than just a
replacement for javascript ;)