Having had a quick look at AS3.0 I have to say that this is a completely different beast from ActionScript 2.0. AS 2.0 compiles to Action Script 1.0 and this has been around in same form since the beginning of the Flash plugin - the changes in each version have been incremental and have not changed fundamentally since Flash 5. What Macromedia have done with 8.5 is to completely and totally change the structure of byte code, though the input syntax is pretty much the same as AS2.0. Reverse engineering the bytecode is difficult without a description either of the VM architecture, or of the file format. There are many blocks of data inside the bytecode that just cannot be interpreted without reverse compiling the VM or the Flex Builder application, both of which may leave the implementor and users open to litigation. If Adobe/Macromedia are serious in their support for Open Source, now might be a good time for them to indicate whether they will be making their VM or file specs open-source in an patent-unencumbered way and when this will happen. Given the the Flash 8 format has not yet been released, I wouldn't hold my breath. I'd love to be proven wrong... Mike??
Still, I would work on the assumption that the format will be published in some form within the next 12 months. If this assumption is correct, there is still a huge amount of work that can be done between now and then. As maybe the only other person on the list that has written a full ActionScript 2.0 compiler (unless some Macromedians are lurking somewhere) I respect what Nicolas has to say about OCAML (I've programmed in Prolog for three years). Indeed, the speed with which MTASC was written is a testimony to this. However this has its own pros and cons. If more than one person was working on MTASC I believe it would have many more features than it currently does, and there would be a much greater dialog between the authors and the community. The choice of OCAML retricted this (though so did Nicolas' choice not to open up the development tree). Other than Ralf's work with HamTASC, there have been no other user contributions to MTASC (this may also be so that MTASC can be dual-licensed?). I also don't believe compilers should be just seen as standalone programs anymore. I went from coding in 'vi', to JBuilder, to Eclipse, each representing a much greater degree of integration between the process of coding and the process of software development and each increased mmy productivity many-fold. Having a extensible stateful compiler that directly embeds into your application is a natural progression and I see many benefits of this approach that more than compensate for having to develop in a more general-purpose language including things such as incremental compilation or caching (KineticFusion can recompile most SWFs in less than a second even after modifying classes - the key word here is 'recompile'). The Flex compiler for example, including the ActionScript bits, is written in Java and my understanding is that it performs very well. Have as ASDT folks not already written an AS2.0 lexer/parser for their Eclipse plugin? My recommendation would be to concentrate on the lexer/parser/semantic analyser for as long as possible. Ensure that as much semantic information as possible is extracted and represented as object references are used in a much more complex way in AS3.0. The code generation bit should probably be the last piece of the puzzle and could be completed in a week by a couple of skilled coders if the documentation is available. I'm not sure the alternative approach of working backwards from the bytecode is a good use of resources for the GENERAL community (I think it's good for individuals to look at so they can still give semantic requirements feedback to the semantic module people). And remember, we're still talking about 12 months before there is going to be any kind of Flash 8.5 presence out there. Just my 2 cents (I'll go back to lurking now!) Alex hank williams wrote: >On 10/25/05, Nicolas Cannasse <[EMAIL PROTECTED]> wrote: > > >>>We are now running machines that are 1ghz to 3ghz. >>> >>>To suggest that OCAML is the only way or that it is "super critical" >>>to making a fast compiler is, to me, ludicrous. >>> >>> >>That was actually my comment :) >> >>But I never said that Ocaml was the only way to make a compiler. >>Try to read my mail again. >> >>Basicly the meaning was that OCaml and in general ML languages (Haskell, >>SML, ...) are the best languages available for writing compilers. It's a big >>lost of time of trying to write a compiler in C/C++ as the author suggested. >>To give you an order of comparison, it would be the same as writing for >>example a Bank account manager GUI system in assembler ! >> >> >> >This does make sense to me. > > > >>This is not about speed. OCaml is very fast and that's a big plus, but the >>flexibility and the power of the language enable people to write compilers >>in days instead of months/years using other languages. That require a lot of >>training before, since you need to learn a new language, a new syntax, and >>even a new way of thinking about programming. But looks like the vast >>majority of people seems to be always afraid of learning new things ;) >> >> >> > >There was obviously some blending between luke hubbards comment that >Ocaml is why MTASC is fast, and your comments. Thanks for the >clarification. > >I do think that you could have said this the first time instead of the >thing about suggesting he "needed to learn about compilers". I dont >mean to beat a dead horse, I just wanted to clarify my point. I think >your insight on the issues is quite instructive and is incredibly >valuable to others on this list. > >Regards >Hank > >_______________________________________________ >osflash mailing list >[email protected] >http://osflash.org/mailman/listinfo/osflash_osflash.org > > > > > _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
