haxe/ocaml port - is it a good idea?

[Ashish Ranjan]

how about writing a port of haxe to ocaml. So that compiler writers who are using haxe to write Different kind of compilers can still get the awesome speed of their final output by "haxe->ocaml" path, but their compilers are itself as much portable 

   1) though haxe/ocaml port can itself be used to write haxe compiler in haxe (and later compile it to ocaml ). Once haxe compiler is written in haxe , it can far greater community participation / patches in enhancing the haxe compiler itself. 

   2) even if one does not agree, even then a valid hscript program speed can also probably benefit by "hscript interpreter translated into ocaml using hxocaml and then compiled to native".

Is compiling the compilers written in haxe to native using hxcpp is enough, or will it far more difference in gain in speed to compile the compilers written in haxe to native using hxocaml.

Ashish

[Ashish Ranjan]

nekoml just borrows syntax of ocaml , it will not be able to match ocaml speed 

here the question is about promotion of haxe as compiler writing language using a new port (say) hxocaml Vis-a-vis  hxcpp.

Ashish

[John Plsek]

I usually don't make frivolous comments on this list ... but

Haxeception :D

Ashish

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

[Baluta Cristian]

Do you want to write any target and you've been put off by ocaml? ocaml itself is not hard, you can understand it in about a week or two, then you'll get better and better when you start writing. I started to write without fully understand it because i was impatient, but now i understand everything i wrote. What is hard is to write a target, so it will remain hard even with a haxe->ocaml target.

Btw, what targets would be interesting? We kind of have everything that's important. cpp rules everywhere.

--
Băluță Cristian
http://ralcr.com
http://imagin.ro

[Stephane Le Dorze]

Not seeing my previous reply appearing, I write it a second time:

an Haxe target could serve two purpose:

- Macro debug / understanding.

- Scaffolding.

No real use case for me as I don't do Haxe these months :'(

[Simon Krajewski]

Am 06.03.2013 09:56, schrieb Baluta Cristian:
> Btw, what targets would be interesting? We kind of have everything
> that's important. cpp rules everywhere.

A mega-optimized Ansi-C target would be great fun. ;)

Simon

[Ashish Ranjan]

ya, you are right .

I am thinking of having hxPython port. But due to seeing haxe compiler's ocaml sources, I was wondering how best one can avoid to read ocaml and still get the blazing fast speed(due to its ocaml implementation) of current haxe compiler. 

  The solution in long run seemed (at that time ) to have a hxOcaml port to convert from haxe to ocaml, and then write haxe compiler in haxe itself. In long run this will be far more productive. 

   But as you said I will try to go straight into ocaml but not for writing hxOcaml, but for writing hxPython.

---

As a reply to your second questions of which other ports one can think of : "hxPython" and "hxLua" are two ports, which one can think of right now. 

 Rather 

       python's scipy 

       and numpy libraries are almost unparalleled 

      and http://expeyes.in/ like python based frameworks etc for teaching school students for science experiments - just visit this website

                                                   http://expeyes.in/python-programming

       many system-config-* utilities of redhat and system APIs from redhat/other linux based commercial vendors for scripting are exposed by default on python only.

        blender supports python scripting

        freecad  - the best free CAD tool, supports python scripting only

        

There are few more things on python like google app engine first class support for python etc ( though probably this can be dealt with hxjava, because app engine also supports java ecosystem.)

"My dream would have been to have a first class python support on haxe, the generated python code should fit well with jython and cython  too. Best thing will be compatibility with python 2.x and python 3.x both the series with some compatibility layer." 

Ashish

[Andy Li]

Hi Ashish,

I am very interested to see a Python target (we usually call it a "target" instead of a "port"). 

Despite of having great science packages, being able to write plug-in or scripting in various software in Haxe would be wonderful. For example, both Maya and Blender ofter Python scripting, which is related to the gaming direction Haxe is heading.

FYI, there was some info Russell Weir was working on a Lua target: https://plus.google.com/u/0/113704686911055424796/posts/gKPjfErbE9F

Best regards,

Andy

[Raoul Duke]

> The solution in long run seemed (at that time ) to have a hxOcaml port to
> convert from haxe to ocaml, and then write haxe compiler in haxe itself. In
> long run this will be far more productive.

£0.02 this sounds sensible to me; i think self-hosting is more than
just a fun circus trick.

[Baluta Cristian]

Writing haxe in haxe is like scraping your left ear with the right hand. You always lose performance when converting because you need some workarounds, sometimes very ugly. Ok, maybe for flash was not the case :P

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

[Hugh]

Hi,

I think it should be pretty viable now to dump the haxe parsed AST to ascii/xml or maybe binary using existing code, then fire off your "haxe backend", which reads this data and generates the output.  You could write this backend in any language, but I guess haxe would seem natural.  This phase will be dominated by file IO, so almost any technology would do - I would suggest starting with neko for portability and convert to cpp is you need some speed from somewhere. A small compiler change, like "--backend myBackend.n" would help.

If someone were to write a "load dumped ast into haxe structures", anyone should be able to write a backend, in haxe, very fast, without having to duplicate the macro/type inference/caching/parsing etc code.

Hugh

[Simon Krajewski]

Am 07.03.2013 05:43, schrieb Hugh:
> Hi,
> I think it should be pretty viable now to dump the haxe parsed AST to
> ascii/xml or maybe binary using existing code, then fire off your
> "haxe backend", which reads this data and generates the output. You
> could write this backend in any language, but I guess haxe would seem
> natural. This phase will be dominated by file IO, so almost any
> technology would do - I would suggest starting with neko for
> portability and convert to cpp is you need some speed from somewhere.
> A small compiler change, like "--backend myBackend.n" would help.
>
> If someone were to write a "load dumped ast into haxe structures",
> anyone should be able to write a backend, in haxe, very fast, without
> having to duplicate the macro/type inference/caching/parsing etc code.

I suggested exposing the typed AST to the macro API a while ago:
https://code.google.com/p/haxe/issues/detail?id=1065#c13

With this you could create a generator via Context.onGenerate, although
it may be necessary to expose a few more helper functions. Back then
nobody commented on it, so I didn't further pursue it.

Simon

[杨博]

I am interested to implement a hybrid target, which just serializes typed AST to file.

It is named hybrid, because this target only serialize part of typed AST, and the rest of typed AST will compile to native target.

And I will create a interpreter, which load the typed AST at run-time. The interpreter will be like hscript, but mine will support fully-feature Haxe, and be able to evaluate the typed AST together with compiled binaries.

在 2013年3月7日星期四UTC+8下午2时27分51秒，Simon Krajewski写道：

[杨博]

OCaml target is a great idea.

The OCaml target will enable people to easily implement other Haxe targets in Haxe, getting rid of the performance overhead in interpreted macros. I hope that Haxe's typed AST will become a universal interchanging format like XMLVM suppose to be.

在 2013年3月6日星期三UTC+8下午3时51分18秒，Ashish Ranjan写道：