4 ms·

Most Haxe targets are source-to-source, with the exception of SWF. It bootstraps on existing toolchains a bit better(this can make a big difference for debuggi

by chipsy 14y ago

Most Haxe targets are source-to-source, with the exception of SWF. It bootstraps on existing toolchains a bit better(this can make a big difference for debugging), and it affords more flexibility in the build process in those situations where you really need to mix in code native to the target. The extra step of compilation to reach the runtime is treated as a UI issue. NME, for example, already has its own build system in order to deal with asset packaging, and it integrates the cpp target compilation alongside that. This doesn't preclude the possibility of bytecode, but from the Haxe perspective it's seen as an optimization, not a must-have for practical use.

jdonaldson 14y ago
I think this is mostly correct. Afaik, the swf (instead of as3) target was provided because the standard compiler (flash) was closed source. Nicolas Canasse, the Haxe language author, wrote an open source as3 compiler called mtasc, and then used his experience to make an optimized compiler for Haxe to swf.
- georgemcbay 14y ago
  mtasc was an AS2 compiler, not an AS3 one. As of Flex3 (~2008) Adobe's AS3 compiler has been open source. (But haxe is still better than AS3, IMO).
  - jdonaldson 14y ago
    You're right, it was as2. I should've mentioned this was true "at the time"
Ralith 14y ago
As a student of compilers myself, it's my understanding that producing bytecode is as easy as--if not vastly easier than--producing code in another language, and that this is particularly true when the target language is high-level. The only exception to this I can envision is when the source language maps easily and completely to every single target language, in which case the source language must be the least common denominator, and the compiler may be a glorified awk script. Significantly, a major feature of the JVM and CLR bytecodes is that targeting them makes it extremely easy to permit interoperation with other code native to the same VM. I'm not sure generating source would be any improvement on this whatsoever. I also question the value of being able to debug generated code; assuming that HaXe is indeed more than a glorified awk script, the process might be compared to using an assembly debugger on C++-generated code. Not entirely useless, certainly, but neither is it precisely desirable.
- jdonaldson 14y ago
  Once again, there's nothing wrong with jvm output. It's "better" for the reasons you say. And, there may be a jvm target down the road. That said, there's a number of situations where providing source code in java/c++ is critical for non-technical reasons... Say, if you want to get your project accepted in one of the various mobile app stores.
  - Ralith 14y ago
    > Once again, there's nothing wrong with jvm output. It's "better" for the reasons you say. So if my understanding, including that bytecode generation requires a comparable amount of effort, why didn't they do that? I don't intend to critique their decisions; I'm interested in why they made them. Their reasoning might well teach me something. > providing source code in java/c++ is critical for ... various mobile app stores. Really? I wasn't aware of that. Are we talking Apple's and Google's? What app store's catalog is predominately C++?
    - benatkin 14y ago
      Why should it be predominately C++, in order to have an easy time being reviewed? There's plenty of C++ code in the iOS App Store. I know a couple of people who've developed most of the code for their iOS apps in Visual Studio. They were computer vision apps with just a little bit of GUI toolkit code.
    - jdonaldson 14y ago
      > So if my understanding, including that bytecode generation requires a comparable amount of effort, why didn't they do that? They might. It's just not what they've chosen to do first. > Really? I wasn't aware of that. Are we talking Apple's and Google's? What app store's catalog is predominately C++? Well, we're talking the iOS app store here. Objective C is the main language, but Apple also supports c++ xcode projects, which Haxe can produce. The reason why Haxe targets c++ is because it can provide garbage collection through the Boehm libs, and (in general) can be made to fit better with the Ecmascript nature of the Haxe language. Google is much less restrictive in terms of supported languages, but their java toolkit is very polished. I also think that source code generation also lets you understand better what the compiler is doing, and how to best take advantage of it. Right now, the java target is very early, but it already has a clever way of handling reflection that is much faster than the standard method. It was interesting to me to read through the generated output, even if it was a little ugly.

by chipsy 14y ago

jdonaldson 14y ago

I think this is mostly correct. Afaik, the swf (instead of as3) target was provided because the standard compiler (flash) was closed source. Nicolas Canasse, the Haxe language author, wrote an open source as3 compiler called mtasc, and then used his experience to make an optimized compiler for Haxe to swf.

georgemcbay 14y ago
mtasc was an AS2 compiler, not an AS3 one. As of Flex3 (~2008) Adobe's AS3 compiler has been open source. (But haxe is still better than AS3, IMO).
- jdonaldson 14y ago
  You're right, it was as2. I should've mentioned this was true "at the time"

Ralith 14y ago

As a student of compilers myself, it's my understanding that producing bytecode is as easy as--if not vastly easier than--producing code in another language, and that this is particularly true when the target language is high-level. The only exception to this I can envision is when the source language maps easily and completely to every single target language, in which case the source language must be the least common denominator, and the compiler may be a glorified awk script. Significantly, a major feature of the JVM and CLR bytecodes is that targeting them makes it extremely easy to permit interoperation with other code native to the same VM. I'm not sure generating source would be any improvement on this whatsoever. I also question the value of being able to debug generated code; assuming that HaXe is indeed more than a glorified awk script, the process might be compared to using an assembly debugger on C++-generated code. Not entirely useless, certainly, but neither is it precisely desirable.

jdonaldson 14y ago
Once again, there's nothing wrong with jvm output. It's "better" for the reasons you say. And, there may be a jvm target down the road. That said, there's a number of situations where providing source code in java/c++ is critical for non-technical reasons... Say, if you want to get your project accepted in one of the various mobile app stores.
- Ralith 14y ago
  > Once again, there's nothing wrong with jvm output. It's "better" for the reasons you say. So if my understanding, including that bytecode generation requires a comparable amount of effort, why didn't they do that? I don't intend to critique their decisions; I'm interested in why they made them. Their reasoning might well teach me something. > providing source code in java/c++ is critical for ... various mobile app stores. Really? I wasn't aware of that. Are we talking Apple's and Google's? What app store's catalog is predominately C++?
  - benatkin 14y ago
    Why should it be predominately C++, in order to have an easy time being reviewed? There's plenty of C++ code in the iOS App Store. I know a couple of people who've developed most of the code for their iOS apps in Visual Studio. They were computer vision apps with just a little bit of GUI toolkit code.
  - jdonaldson 14y ago
    > So if my understanding, including that bytecode generation requires a comparable amount of effort, why didn't they do that? They might. It's just not what they've chosen to do first. > Really? I wasn't aware of that. Are we talking Apple's and Google's? What app store's catalog is predominately C++? Well, we're talking the iOS app store here. Objective C is the main language, but Apple also supports c++ xcode projects, which Haxe can produce. The reason why Haxe targets c++ is because it can provide garbage collection through the Boehm libs, and (in general) can be made to fit better with the Ecmascript nature of the Haxe language. Google is much less restrictive in terms of supported languages, but their java toolkit is very polished. I also think that source code generation also lets you understand better what the compiler is doing, and how to best take advantage of it. Right now, the java target is very early, but it already has a clever way of handling reflection that is much faster than the standard method. It was interesting to me to read through the generated output, even if it was a little ugly.