Haxe 2 Dart proof of concept

[Andy Vernon]

I've written a proof of concept to generate dart output from haxe source code: https://bitbucket.org/AndrewVernon/hx2dart 

It's far from complete but I wanted to see if there's any interest in the Haxe community and if anyone else wants to contribute.

So far I've only tested it on my macbook so please let me know what problems are encountered. I

From what I've read there in the haxe mailing lists there are mixed reactions to dart but I think most of the negative ones are viewing dart more as an alternate language and environment to develop in rather than another potential target platform (hopefully a major improvement for web apps in particular although I guess this remains to be seen).

At this stage I'm using the js target and everything is implemented with haxe macros as a Custom JS Generator.

To go with this I've also started a proof of concept to cross compile haxejs projects directly to dart hxjs2dart. To make it easy for anyone to test I've included this in the hx2dart source for now along with a helloworld example. Ideally any js project written in haxe3 will be able to automatically cross compile to dart. There would then probably be room for further optimisations although in theory the project should already out perform the js equivalent.

[Cauê Waneck]

Oh wow!! Those are fantastic news, Andy! Thanks for sharing!!!

I hear that there are a lot of functionality specific to Dart (e.g. SIMD access), it'll be awesome to take advantage of that in Haxe! :)

2013/9/30 Andy Vernon <andy.d...@gmail.com>

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

[Philippe Elsass]

Nice!

 

I didn't try it but as I used Dart, even if typing is optional, there are various things that can hint the VM to use faster code; like testing if an array is really an array before doing a loop:

if (a is! List) return;

for(i in a)...

 

So I wonder, could (does) the transformation replace Std.is(t, T) by the 'is' keyword?

 

There are also gotchas with numbers.

 

Interesting project for sure :)

 

Philippe

 

--
Philippe

[Heinz Hölzer]

awesome work, dart would be an awesome addition to the haxe targets ;)

do you think the js generator approach is sufficient? I wonder if it would be possible to create a python target in the same way.

best,

h

[Andy Vernon]

The js generator approach is just temporary to get things going quickly and hopefully get more people involved. I'm not sure exactly what downsides there will be but for someone like me who is a noob with ocaml and fairly comfortable in haxe it seems like a good way to get started trying to generate another language. I did hack around in ocaml using the genas3.ml and genjs.ml to output dart and got to a similar place but I thought that as the customJS version allows anyone to try things out and work on the generation without having to recompile the haxe source it might get things moving. 

From what I understand already the expanded pattern matching syntax in haxe3 is very close to how the ocaml generation of each target is written so it should be possible to rework the CustomJS generator version in haxe to a point where it's working well before porting it to ocaml (please correct me here if I'm wrong about this)

[Andy Vernon]

At the moment Std.is is being replaced by the "is" keyword but there's already issues as the "is" keyword only works when types are known at compile time in dart. (checked mode will catch this though)

eg. in haxe: 

 var type:Dynamic = String;

        trace(Std.is("string", type));  //true

        trace(Std.is(1, type));     //false

but in dart:

    var foo = String;

    print("string" is foo);  //true

    print(1 is foo);   //true

I haven't thought to hard about how to handle stuff like this yet though. I assume the other targets have already covered similar issues with some compile time checking and reflection when needed. At this stage though everything is just proof of concept and I'd expect lots of edge cases will need to be handled but hopefully between all the other targets many of the problems have already been solved.

[Simon Krajewski]

Am 01.10.2013 00:22, schrieb Andy Vernon:
> The js generator approach is just temporary to get things going
> quickly and hopefully get more people involved. I'm not sure exactly
> what downsides there will be but for someone like me who is a noob
> with ocaml and fairly comfortable in haxe it seems like a good way to
> get started trying to generate another language. I did hack around in
> ocaml using the genas3.ml and genjs.ml to output dart and got to a
> similar place but I thought that as the customJS version allows anyone
> to try things out and work on the generation without having to
> recompile the haxe source it might get things moving.
>
> From what I understand already the expanded pattern matching syntax in
> haxe3 is very close to how the ocaml generation of each target is
> written so it should be possible to rework the CustomJS generator
> version in haxe to a point where it's working well before porting it
> to ocaml (please correct me here if I'm wrong about this)

A year ago I would have called you crazy for _not_ doing this in OCaml,
but with the improvements haxe has seens since then I'm not so sure. If
it turns out to be sufficient, I see no reason to hastily move to OCaml.

You may want to check out my pull request which exposes the typed AST to
haxe macro context:
https://github.com/HaxeFoundation/haxe/pull/2022

This would allow you to access the same information the OCaml generators
have by using a Context.onGenerate() callback. I'm still looking for a
precedence use-case to convince a certain Frenchman that this is a
worthwhile addition. ;)

Simon

[Andy Vernon]

I'd definitely been in favour of having access to the typed AST in the haxe macro context. Would be great to be able to have a version of one of the generators ported entirely into haxe to start a new target from. I think it would also then make it a lot easier to write the OCaml version for people without much experience there.

[Andy Vernon]

I've added some more samples from the  https://www.dartlang.org/samples/  concentrating on the hxjs2dart side at the moment.

At the moment I'm just working through them and trying to get the haxe equivalents running in dart and js. 

For the solar sample I've included multiple versions which all render the same thing for comparison:

-solar.dart : 5.6 KB                         (original dart source) 

-solar.hx.dart   : 4.9 KB                  (doesn't include comments from solar.dart though)

-solar.min.dart  : 2.7 KB                 (original source minified by dart2js compiler) 

-solar.hx.min.dart : 2.9 KB             (solar.hx.dart minified by dart2js compiler)

-solar.dart.js : 87.0 KB                    (original dart compiled to js by dart2js compiler

-solar.hx.js :  7.9 KB                       (haxe javascript output)

-solar.hx.closure_min.js 4.3KB    (hx js minified by closure compiler)

The closure compiler was unable to compile the dart2js javascript at any level.

I'd definitely expect the dart2js generated js to improve significantly in the future but at this stage it's no where near as good as the haxe output considering it's it's producing exactly the same result in the browser. The hx2dart dart output is fairly close to the original dart in terms of file size although is still very much only proof of concept.

I haven't had a chance to do any comparison of performance yet but will hopefully get some versions of these benchmarks https://www.dartlang.org/performance/ ported soon. 

[JLM]

Andy how feasible would it be to output typescript as well, just curious really?

[Andy Vernon]

From what I've read about TypeScript I think it would be less effort than dart. 

Areas where they will probably start to vary significantly are things like reflection however I think it could implemented in a very similar way to how it's handled in haxe's js (if not one of the other targets) to get things started at least if Reflection is a priority. 

If anyone wants to try another output like TypeScript in a similar way I'd probably recommend starting clean with the original haxe.macro.ExampleJSGenerator  and haxe.macro.Printer and comparing with what's going on in the dart versions because I've chopped them up and hacked around just to get something going and I may have removed some really useful stuff.

These types of projects would probably all feed into each other a lot also and benefit from the pull request Simon was talking about: https://github.com/HaxeFoundation/haxe/pull/2022 

[David Peek]

Why on earth would you want to target TypeScript? Just curious.

On Friday, 4 October 2013 01:01:45 UTC+10, JLM wrote:

[Philippe Elsass]

Targeting Typescript doesn't bring anything useful imho - don't forget it's just syntaxic sugar on JS so this would just add an additional build step.

Dart is barely more useful, but at least it has a native VM which seems to offer some performance improvements over JS.

--

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.

--
Philippe

[Andy Vernon]

Use cases for generating typescript output from haxe might include:

  - creating interfaces (externs) to allow TypeScripters to use haxejs libraries in a strongly typed way 

  - generating / porting haxejs libraries or projects entirely as TypeScript for the same reason as above 

  - some people may prefer the js Typescript compiles to more than the default hx js  (although this could be generated directly from haxe without outputting typescript first)

 - someone might get paid to produce typescript but prefer to code in haxe

 -  typescript is being realigned with ecmascript6 which browser vendors are working towards implementing (no guarantees obviously)

    (ecma has also proposed standardising dart) 

The companies producing typescript and dart are no small players let alone the development communities that surround them. 

If you search for the market shares they have in the browser world and smartphone / tablet world the numbers and therefor potential here is significant.

dart and typescript targets are definitely not very useful today but neither would the swf9 target have been much use before flash player 9 was released. How useful they may be in the future is a different question with no guaranteed answer at this stage but educated guesses can be made.

The beauty of Haxe is that it's not tied to any platform and therefore as long as community members continue to experiment with new targets haxe developers should feel more confident than most that their hard work and knowledge will remain relevant no matter what happens.

[Philippe Elsass]

Ok, I like the idea to generate typescript externs...

[Heinz Hölzer]

Hey Simon,

i'm currently working on a python target using the same technique, most of generation works without big issues (i guess generation for dynamic targets is much easier ;)).

But at some points you really need the typed ast. String concatenation is an example for this because python does not convert types implicitly to string and throws an error. But i guess if i would have the typed ast it would be quite easy to handle cases like this. From my experience so far i have to say that it's definitely possible to write a target in haxe and i guess it's also better for collaboration. So please tell nicolas that your pull request for exposing the typed ast is very very useful.

You can find the current state of the target here:

https://github.com/frabbit/hx2python

and some already working output here (python 3.3):

https://github.com/frabbit/hx2python/blob/development/bin/hxpython.py

@Andy thx for your dart target, i took it as a starting point ;)

best,

h

[Cauê Waneck]

Oh wow! That's awesome, Heinz!

2013/10/20 Heinz Hölzer <heinz....@googlemail.com>

--

[Marcelo Serpa]

That's inspiring… perhaps a Ruby target would make sense as well, at least would possibly allow interoperation with existing Ruby apps made with say, Rails; or better: taking advantage of the extensive Ruby ecosystem.

This post on reedit: http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_language/?utm_source=rubyweekly&utm_medium=email; made me think on trying statically typed languages again, and Haxe is the first thet comes to mind :)

-- 

Marcelo

[Heinz Hölzer]

from my python experience i would assume that the ruby target should be quite easy to implement. The harder part is creating nice and efficient source code ;).

I'm currently generating everything into one module which is not really pythonic i think, but is a lot easier to handle from the generation point of view. I would do the same for ruby.

[Andy Vernon]

This is fantastic Heinz!

I haven't had a chance to do any more on the dart side for a while as I need to pay some bills but I see you've got a lot further with the python generation so hopefully I'll be able to feed some of your work back in to make more progress on the dart output. 

Would be good to get an indication if we're going to see Simons pull request merged anytime soon in which case we could compile a version of haxe from the pull request now and get started with the typed ast.

On another note I posted about the hx2dart project on the dart mailing list and it didn't get much feedback except one of the guys from google said he had previously started on a dart2haxe project that never got finished. I had thought a little about generating haxe from other languages before but it got me thinking that potentially adding other languages as frontends to the haxe compiler (of forks of it) could allow many others to benefit from all the possibilities of haxe and therefore have more developers feeding back into haxe itself and the haxe targets. Not that there's anything wrong with the haxe syntax at all but embracing other languages as frontends along with their developer communities  could have big possibilities. It's just a pipe dream that I haven't thought much about the feasibility of and would obviously be a lot of work but I thought I'd throw it out there (not sure if anything similar has been discussed before). Imagine a compiler that compiles both haxe and dart source for example out to all haxe targets but also could extend dart syntax (".hart"???)  to add advanced haxe features like macros for dart developers. I don't usually hold much value for unexecuted ideas but the world needs dreamers... ;)    

[Heinz Hölzer]

Hey Andy,

i'm not sure if you will be able to put some work of mine in your target because python is really special (limited lambda support, explicit variable scoping, obligatory indentation etc. etc.). I also need to clean up a lot (but i'm waiting for the typed expression support and yes it would be nice to get the pull request for the next haxe release.).

Yes different frontends are interesting although macros lessen the needs for them a bit. However i think the most important thing is to enlarge the community and new backends could help a bit.