incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Smith <gosm...@adobe.com>
Subject RE: [gosh] Compiler choice [was Goshawk language choices and more]
Date Tue, 21 Feb 2012 20:43:08 GMT
> The mxmlc compiler is far from perfect, but it exists and works already
> My gut feeling is that you are right and that we should strive for something new rather
than trying to improve it.
> I just worry we might have been too hasty in completely disregarding it.

At Adobe we had several months of discussions about improving the old compiler versus starting
over with Falcon. The main reasons we decided to start over were

1. We wanted a compiler that could do double-duty as the code-intelligence engine for Flash
Builder, rather than being something completely separate that Flash Builder called to create
a SWF or SWC. That way you don't have duplicate data structures and duplicate algorithms,
and you can have live error highlighting based on accurate semantic analysis. We ended up
taking Flash Builder's code intelligence engine, improving it, and adding semantic analysis
and code generation to it. (The resulting Falcon compiler doesn't have dependencies on Flash
Builder though... it's the other way around.)

2. The old compiler wasn't designed for compilation on multiple threads. We wanted a compiler
that was designed with concurrency in mind from the beginning, as a primary way to get better
-- and scalable -- performance.

3. There was an awkward relationship between the old asc (which essentially understands only
how to compile a single .as file) and mxmlc (which layers on top multi-file compilation and
support for .mxml, .css, .properties, and .fxg), based on their historical development by
two separate teams at Adobe. We wanted a single compiler, designed by a single team, that
had a unified architecture, unified data structures, and multi-file / multi-language support
from the bottom up.

I'm not saying that it would have been impossible to improve the old compiler in these directions,
just that we decided we were more likely to make faster progress by starting over.

Personally, I'm hoping to see the timetable for opensourcing Falcon accelerated, but I'm just
an engineer and don't make scheduling decisions.

- Gordon Smith, Falcon team, Adobe

-----Original Message-----
From: David Arno [mailto:david@davidarno.org] 
Sent: Tuesday, February 21, 2012 2:16 AM
To: flex-dev@incubator.apache.org
Subject: RE: [gosh] Compiler choice [was Goshawk language choices and more]

> From: Left Right [mailto:olegsivokon@gmail.com]
> Sent: 20 February 2012 16:00
>
> Well, HaXe can use pre-compiled code, since maybe more then a year ago 
> I guess... It doesn't use SWC, but ans SWF as an input is OK.
> Probably Niel can elaborate on that, or correct me if I'm wrong.
Yeah sorry I wasn't very clear on that. The problem with viewing SWFs as a usable input source
is that they are only of use when targeting SWFs. haXe doesn't have any target-agnostic library
support.

> I never found any practical use case that justified the use of 
> internal or

> custom namespaces ... I see the absence of E4X as a good thing ...
Whether you, I or the framework use such features isn't the main issue though as far as I
can see. Unless we are imagining we would port the framework to haXe, but then tell SDK users
to carry on using AS3 and the mxmlc compiler, we have to allow for the fact that both features
are used in the wider community. Therefore I think that until a way to seamlessly handle those
features in haXe is devised, it will be a difficult sell to the wider community.

> Why not use MXMLC? - obviously, Adobe aren't going to support it, 
> unless for maybe critical fixes, so if you are going to support it, 
> you are quite on your own with that.
We will be on our own regardless of which compiler we choose, surely? The mxmlc compiler is
far from perfect, but it exists and works already. My gut feeling is that you are right and
that we should strive for something new rather than trying to improve it. I just worry we
might have been too hasty in completely disregarding it.

David.


Mime
View raw message