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