OCamlScript might help any effort to make Haxe compiler self-hosting

[Rezmason]

Hey folks!

I know there are some people in our community feel that Haxe being able to compile itself would carry a kind of symbolic implication about its maturity as a language.

There are other people who probably think it'd simply be cool to compile Haxe in Haxe. I guess I belong in that camp, though it's not a personal priority.

As it turns out, the company Bloomberg has put a public project called OCamlScript on GitHub. It's supposedly in the early stages, but it claims to compile OCaml to JavaScript. This might be a useful step for transforming Haxe's OCaml source into code that is more similar to the Haxe syntax, so I wanted to put it on your radar. :-)

[Marcelo de Moraes Serpa]

> then replace Neko as Haxe primary VM

You raise a good point there. Neko is pretty lacking in some areas (like lacking good debugging tools, and bindings to C libs). What other VM would be suitable for Haxe? Maybe V8? Would that even be feasible?

On Fri, Feb 5, 2016 at 2:31 PM, PeyTy <aleg...@gmail.com> wrote:

Hello, Rezmason! Some time ago, I even wrote direct OCaml -> to Haxe transpiler, so JavaScript is "so yesterday". :D
But it sucked. Haxe compiler written in the unportable way, so nope.
I am still working on LLVM backend for Haxe, because main reasons for OCaml are:
- Native superspeed
- Bindings to native libraries
! But it lacks of fast macro execution.
Adding LLVM will solve macro problem, then replace Neko as Haxe primary VM, and only than we can rewrite compiler mostly FROM SCRATCH
and achieve good speed, nativness and self-hosting.
If you have experience in OCaml+LLVM help will be appreciated.
Have a good day!

--
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.

[Ashiq A.]

For game development, Neko is quite good. It's easier to setup than the debug version of Flash Player, and it's easy to package up Neko apps with all their dependencies together (without requiring an installer).

But, I never had a working Haxe debugger (or even auto complete in an IDE), so I can't comment about the debugging side ("trace" is as far as I go).

[Marcelo de Moraes Serpa]

> I hope to join Haxe Foundation to work fulltime on this :)

Great :)

ping @HaxeFoundation!

[Simon Krajewski]

Am 06.02.2016 um 00:35 schrieb PeyTy:
> @Marcelo I must to make Proof-of-concept first! =)

We (well, Nicolas mostly) are currently working on what it basically the
successor to neko. Check out genhl.ml at
https://github.com/HaxeFoundation/haxe/tree/hl.

It's not yet passing all unit tests and there's only the interpreter
right now.

Simon

[Nicolas Cannasse]

Le 06/02/2016 01:13, PeyTy a écrit :
> It is very sad to read this https://medium.com/@ncannasse/some-words-about-haxe-foundation-e97a4e9d7e41#.mif22v3nl and then see such innovative "nobody knows what" piece of code.

Come on, don't take such a stance.
It's not yet announced and will not be until I consider it ready. I can
say it's still experimental as for now. Hence no doc.

Nicolas

[Philippe Elsass]

Debugging? Debugging debugging debugging, debugging!

Speed? Bonus.

On 6 Feb 2016 11:44, "Oleg Petrenko" <aleg...@gmail.com> wrote:

Wow, hello, Nicolas! Thanx for response! I ll study sources then and privately mail you about pros and cons, if you are open to discussion.

суббота, 6 февраля 2016 г. пользователь Nicolas Cannasse написал:

--
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 a topic in the Google Groups "Haxe" group.

For more options, visit https://groups.google.com/d/optout.

[Hugh]

Just to work out what you are trying to do here.

You have put ocaml->haxe converter on hold, and decided to directly write a LLVM backend?

The idea being that this backend would then #1 run macros faster, and #2 produce executables in its own right?

While it is true that llvm can generate "ultimately" fast code, I think haxe performance is going to be more about how you handle Dynamic, interface inheritance, GC and a few other features.

It is also quite a big dependency - possibly in the order of the JVM?  If you had haxe-in-haxe, the JVM would be the easiest way to get JIT macros.

If I added JIT to cppia, then I think hxcpp would be the smallest/lowest dependency way to get JIT macros - again assuming haxe-in-haxe.

Hugh

 .

[JLM]

I have been having fun and games with push in as3 and Array pooling  at work :( .
So I was just curious if there are plans to have pooling built into HL or will the memory be designed so pooling is not really needed?
Had a quick look at how arrays grow.

(size * 3) >> 1;
https://github.com/HaxeFoundation/haxe/blob/hl/std/hl/types/ArrayObj.hx#L212

But wondered how expensive creation of an array or list would be on HL.
https://github.com/HaxeFoundation/haxe/blob/hl/std/hl/types/ArrayObj.hx#L10

And if Pooling had been a consideration in the design or even relevant.

[Nicolas Cannasse]

I have not yet worked on the GC, but I expect allocation to be quite
fast, making pooling not that much interesting unless for cases when you
do a lot of recycling (particles spawning/dying for instance).

Best,
Nicolas