Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Received-SPF: pass (google.com: domain of roland@stackandheap.com designates
 10.50.179.106 as permitted sender) client-ip=10.50.179.106;
MIME-Version: 1.0
In-Reply-To: 
 <CAJQBtgneq2UkgmJk2Wv2HMg13kYB9=8o2ubAeH+xX_w4vbcJBw@mail.gmail.com>
References: 
 <CAJQBtgneq2UkgmJk2Wv2HMg13kYB9=8o2ubAeH+xX_w4vbcJBw@mail.gmail.com>
Date: Sun, 19 Feb 2012 10:57:43 +0100
Message-ID: 
 <CAAgciqog-RaBdKmnxmfRfP4CNSD1Ow5cMAU0Ed56b8do=zFbCA@mail.gmail.com>
Subject: Re: Adobe / Apache / Spoon Flex Tour
From: Roland Zwaga <roland@stackandheap.com>
To: flex-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=14dae934041391aa9104b94e35ef

--14dae934041391aa9104b94e35ef
Content-Type: text/plain; charset=ISO-8859-1

>
> First of all. Why Java (JVM)? Why use this piece of corporative neo-COBOL
> invented for the sole purpose of allowing cheap labor force to further
> bloat the bloatware? For once you have the full carte blanche to start
> anew, and you choose nearest to worst option? Compiler is unlikely to drive
> a lot of attention of the programmers typically writing in Java. On the
> other hand, programmers who are interested in language design are very much
> unlikely to be attracted by Java. I'd look into the following options,
> which are all viable, in my opinion:
>

I think the main reason for using the JVM is because of the amount of Java
(and other
JVM languages) knowledge that is available.
The other languages that you suggest probably have lots of advantages over
Java but,
from what I know, they are not very widely adopted. Should a new compiler
be built
it would be very important that it'll be extensible. So that people will
have a low barrier
for creating their own extensions to it. If they are required to develop
these extensions
in a language that they haven't ever used it would automatically require
them to learn
a new language while all they want to do is build a simple compiler plugin.
For a lot of folks that would be reason enough not to pursue the idea in
the first place.
When choosing the JVM they can choose from any of the available JVM
languages,
not necessarily Java.
It might be worth considering building certain parts in C I guess, but that
would add the
extra burden of making sure the C based parts are cross-platform compatible.
I mean, I'm pretty sure the aim is to have a compiler run on windows, mac
and linux.


> ANTLR - is the tool for automatic parser generation. It may or may not _at
> all_ apply to ActionScript. I would be rather surprised if it did, since
> AS3 has extremely convoluted grammar (feels like it might be too ambiguous
> for this kind of parser), especially due to E4X, but the metadata is
> another weird subject. The rules pertaining to semicolon aren't helping as
> well. Lastly, there were many arbitrary decisions made by the MXMLC
> authors, which, de facto become AS3 standards, but need not to be such.
> Examples: there may only be one public definition per file - this is kind
> of random, and is this way solely due to the way MXMLC caches the
> definitions it finds. It's not even a technical limitation, it's something
> done long ago in order to speed up the compilation process, some very early
> versions of MXMLC allowed more then one public definition per file.
>

I know the perils of parsing AS3 because of its 'interesting' language
features.
It might be difficult to build such a parser, but its not impossible,
seeing that quite
a few IDE's and libraries (
https://github.com/teotigraphix/as3-commons-jasblocks)
have already managed to perform this task. (Jasblocks parses AS3, MXML,
Regex and E4X).
You neglected to mention an alternative though, if AS3 isn't suitable, in
your opinion, to be
parsed using a grammar based approach, what would be the alternatives to
this approach?


> AS3 per se has no formal grammar definition, and, in certain cases you
> would be either forced to follow the existing implementation, or make an
> arbitrary choice based on "what feels right". This is especially so because
> on different stages of MXMLC development different features have been
> dropped or altered. For example, once it was possible to provide a complex
> expression in place of the type specifiers. Example: var
> foo:(getTypeOfFoo()) = functionThatReturnsFoos(); would've compiled. I.e.
> compiler could do some sort of type inference / something similar to "auto"
> from C++, but never more.
>

These language constructs you mention seem very interesting, there's been a
discussion
on the list already about adding new keywords and constructs to AS3. People
weren't
sure whether it was a good idea though to start moving away from the
'standard' AS3
language specs that Adobe tools support. But I'm guessing these might be
added
using a compiler switch so that people can decide for themselves whether to
use the
'advanced' features or not.
This debate hasn't ended though, so feel free to share your ideas.


> Old compiler was essentially dumb, when enforcing certain AVM specific
> policies, thus allowing essentially wrong code to compile. For example, in
> constructor if (1 == 2) super(); would generate the code, that never calls
> the super constructor... This is only an example, there's a lot of this
> kind of surprises. You would need to treat that somehow, decide what to
> keep and what not to keep, when should you issue warnings etc...
>

The issues with the old compiler are widely known, so I think everybody
agress
with you here :)


> MXML is an extremely unthoughtful template language, it is in many aspects
> very evil. I cannot imagine anyone who used it for a real world project and
> never wished this thing just vanished as a nightmare. It is so wrong in so
> many ways... inability to set properties to constant values / expressions.
> It is forcing you to copy-and-paste approach, it is sometimes more wordy,
> then the similar AS3 code! Example:
>

I'm not sure what your personal frustration with MXML are, but I'm pretty
sure most
people using Flex loved how you can express a UI quite easily with it.
You mention you can set properties using constants or expressions, doesn't
this
do exactly what you metniod?
<fs:DataGridColumn label="{Foo.BAR}" labelFunction="{labelFunction"}/>


> <fx:DataGrid ...>
> <fx:columns>
> <fs:DataGridColumn label="{Foo.BAR}" labelFunction="{labelFunction"}/>
> <fs:DataGridColumn label="{Foo.BAZ}" labelFunction="{labelFunction"}/>
> <fs:DataGridColumn label="{Foo.BOOZ}" labelFunction="{labelFunction"}/>
> . . .
> <fs:DataGridColumn label="{Foo.CHAMPAIGN}"
> labelFunction="{labelFunction"}/>
> </fx:columns>
> </fx:DataGrid>
>
> You copied words "DataGridColumn", "label", "Foo", "labelFunction",
> "labelFunction" how many times? Whereas you could do:
>
> var dataGrid:DataGrid = new DataGrid();
> for (var p:String in Foo) dataGrid.columns.push(makeColumn(p));
> function makeColumn(label:String):DataGridColumn { return ...; }
>

I think it would be rather hard to express a loop construct in an XML
dialect,
I'm sure it's possible but then you'd be creating a programming language
in XML which kind of defeats the purpose. All in all I don't think MXML is
THAT
verbose. The data column example you mention is an exception, IMHO.
Sure, MXML is open to improvement and should you have any input for this,
please share with us. But suggesting to simply 'dump' it seems a tad
over-enthusiastic :)


> Almost no editor today provides any good tools for working with MXML -
> yeah, I tried Intellij and FDT - it just doesn't work properly, since no
> sane spec of MXML had ever existed, certain implementation treated it as
> they thought it would function or just didn't give it a second thought, so
> it functions essentially wrong.
>

Again, I don't share any of these experiences, aside from FB I thought FDT
and IntelliJ
handled MXML rather well. The only failure in FB, IMHO, was the design
view, but this
was more the fault of the FB implementation that it was MXML's fault.


> I don't believe anyone really wishes to keep this thing, if only, for
> retrospection and maintaining old projects. Seeing how many mistakes in
> design were made in this particular place, I'd say that if you want good
> code, backwards compatibility will likely became a major obstacle. Adobe
> may have certain obligations in this regard, but, seriously, I don't see
> why would any of you feel obligated to keep this dark legacy alive :)
>

I feel you make rather harsh points, the few criticisms you have on MXML
don't
seem to warrant a direct abandoning of the language. Of all the problems I
personally
have with Flex I must admit MXML certainly isn't on the list. Again, sure
there is room
for improvement, but I am very hard-pressed to consider it a 'dark legacy'.


> FXG - important! This was generated by MXMLC too! Don't forget it :) The
> way it was generated, however, was not good - for some obscure reasons,
> whoever wrote this part of the compiler decided to force the use of some
> Spark containers as base class - this needs not be such! This essentially
> killed the feature. This and the whole linker-related issues - totally
> useless Flex***Asset classes, the [Embed] tag - obscure and promoting bad
> practices... how are you going to support that? [Bindable] - another very
> controversial feature - it is essentially evil, since you can't force it to
> use your own template for code generation. But probably you need a whole
> more generic solution for code generation based on metadata?
>

The metadata related issues I agree with and these would have to be
addressed in a
new compiler. People definitely ought to be able to use their own
templates, for instance,
to add their own flavour of data binding. I am not sure if Falcon supports
these features,
but if Goshawk should ever move from an idea to an actual code base this is
a feature
on the 'must have' list.


> How about providing a better interface to linker - not anything you'd need
> to write a Java module for, but just use output from Imagemagic / DevIL /
> GD etc?
>

Great idea!


> JavaScript related stuff - first of all why bother? :) Alright, that's just
> my opinion. But wouldn't it be better to generate some common intermediate
> language, like LLVM and let whoever wants it to use tools that can
> translate LLVM to JavaScript, something like JSC? I mean, after all this is
> an ActionScript compiler for Flash - JavaScript is a separate community,
> with their own stuff, leaders and blah :) - why not let them use their
> Closure and be proud of themselves? Anyway... just saying.
>

The Javascript output discussion is still in full effect. I think people
agree that it would be
a huge boon should a Flex application be able to be cross-compiled to a JS
output.
HOW this would work in practice is still very much up for debate and
probably needs a whole
bunch of research. Your suggestion to use an intermediate format like LLVM
seems to be
like a very sensible option, just because there's already a lot of LLVM
related knowledge,
libraries and tooling available.
But JS support would be just one of several targets that a future compiler
would be able to
support. I mean, maybe it would even be a feasible plan to support Chrome
Native Client?
Who knows, if the compiler is flexible enough people would be free to build
their own target.


> SWC - is not only a code repository, it's essentially a way to store
> whatever you might have in the project. I think it would be wise to reuse
> this idea. Probably limit oneself to the versions and the content of the
> SWC one will understand, but I don't see how it makes sense to discard the
> entire feature, or to rename the file. You can already stuff it with
> JavaScript files, if you want to, no changes to the format are needed.
>

I think the idea of David Arno to store the Goshawk intermediate output as
a library format
is quite brilliant, especially when considering multiple back-ends. SWC
could still be supported
in its current form, it would simply become another back-end target. So I
don't think its support
will be discarded very soon.


> Static analysis - will the new compiler be an optimizing compiler? (A short
> question, but this is essentially would be the biggest part of the
> compiler, if it will ever be).
>

I can't speak for Falcon, from what I understand the compiling speeds have
been improved, not necessarily
the opcode output. An alternative compiler would definitely need a proper
optimizer IMHO.
Maybe we could kidnap Joa Ebert for a couple of months? ;) :)


> Conditional compilation... is... well, dramatically bad in MXMLC. It's not
> a standard of any ECMA-whatever, are you going to keep it at that, or just
> redo the whole thing? I'm so for redoing it...


I guess my answer would be the same as for your question about the
optimizer ;)

cheers,

Roland

--14dae934041391aa9104b94e35ef--