Hello. Sorry, I wasn't registered when this thread started, so if my message didn't end up in the proper thread, I hope the moderators will move it.
Basically, this thread has helped me to make up my mind and register :) Some of you may know me as a loudmouth annoying debaucher person, and this post has a tendency to end up as such, but I'm begging you to treat it with a bit of irony. Well, consider yourself warned! :) So, there's not much yet to discuss in the new compiler architecture, however, there are certain things I'd like to bring up as a potential user. I was actually waiting for Adobe Falcon compiler to get into any shape, so I would start working on my "dream project" - an AS3 mode for Emacs :) Seeing how the future of AS3 compiler is now in question, I'd like to chime in. 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: Go - the Fortran-like (or, if you prefer, C-like) language. A kind of an effort to fix long-standing Java problems. It is not an ideal language, but it is a good replacement for Java for people who grew on Java. http://golang.org/ Haskell - a beautiful language! Bonus points, it has developed tools for parsing code using formal grammar. http://www.haskell.org/haskellwiki/Parsing_a_simple_imperative_language C - no-bullcrap, plain old C if you want to squeeze the last bit of performance. Common Lisp - a very versatile, in fact, much more modern in certain aspects then Java, language. Extremely well suited for building intermediate code, manipulating (optimizing) parse trees. The perfect tool for code generation. Writing the tools for AS3 in lisp will very much broaden the horizons of AS3 programmers, let them be exposed to more programming concepts (this, of course applies to other options too, to a variable degree). Any variant of ML/Miranda-like language (be it CaML or Erlang, I've mentioned Haskell already) simply because you have a very good compiler implemented in CaML (HaXe, which is very similar to AS), and you could've borrowed certain ideas from it. * * * 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. 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. * * * 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... 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: <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 ...; } 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. 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 :) This all was written as an attempt to convince you to write your own w/o considering the heritage, since the heritage may be at the same time bad and unwelcome to the end users. * * * 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? 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? * * * 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. * * * 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. * * * 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). * * * 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... Sincerely yours. Do I have to remind you about taking the above with a bit of irony? Alright :) wvxvw
