On Sat, 2012-02-18 at 21:48 +0200, Left Right wrote: > First of all. Why Java (JVM)? The JVM gives us many advantages: 1. Java - which whilst long in the tooth is well known and well supported and - a point that is difficult to overstate - its the language that Flash Builder and FDT and IntelliJ are all written in. Dismissing Java as "corporative neo-COBOL" is a little silly. 2. It offers easy-cross platform support. Making something that runs on Windows and Linux and OS X, without caring about the target OS, is very easy with JVM-targeted languages. 3. It's a fast, universally available, well supported, will understood managed memory environment.
Sure it has disadvantages (the seriously crap need to tell the application how much maximum memory its allowed to use via obscure command line options being the worst in my view,) but I'd contend that the benefits outweigh those disadvantages. However, if you think that people with no interest in Flex will come flooding on to this project to help write a compiler if we propose writing it in in a technology that doesn't target the JVM, then I'm more than happy to go with a different language. > 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. What benefits exactly would Go offer? How many compilers have been written in Go? Surely Go is just one of Google's many many projects that they frequently throw at the wall to see which stick. Go didn't stick as far as I know. > Haskell - a beautiful language! Bonus points, it has developed tools for > parsing code using formal grammar. It might be beautiful if you have a degree in maths. To most programmers, it's incomprehensible gibberish :p By all means feel free to write a Haskell-based compiler, but count me out if you do. Life is too short for me to waste it on a language so complex, no one seems to be able to explain what a monad is in less than a one hour talk... > C - no-bullcrap, plain old C if you want to squeeze the last bit of > performance. Ha ha. This made me laugh. You call Java a Cobol-like language, then drag up a language I used to have to write on VT100's some 25 years ago! :) Seriously, C should be a language of last-resort. It's really not very nice. > Common Lisp (One (day (we (may (all (have (to (learn (to (use (Lisp (but (until (then (I'd (prefer (to (pretend (it (died (40 (years (ago, (buried (under (its (own (insane (syntax))))))))))))))))))))))))))))) > 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. haXe is written in OCaML. As a result, one person maintains the compiler, because no one else knows it... > AS3 per se has no formal grammar definition,... I reckon http://svn.badgers-in-foil.co.uk/metaas/trunk/src/main/antlr/org/asdt/core/internal/antlr/AS3.g would form at least a good starting point for this non-existent formal grammar. > JavaScript related stuff - first of all why bother? :) Because we don't have any choice. Whilst it is a huge pile of steaming shit, and I'd love to punch Brendan Eich in the face for being so proud of inflicting such an awful mess upon humanity, it's here to stay and is the future of programming for the foreseeable future. > Alright, that's just > my opinion. But wouldn't it be better to generate some common intermediate > language, Yes, that's why I suggested the front-end and back-end separation of Goshawk. The front-end will be written using something like ANTLR and so will be programming-language agnostic. It will save its results as lib files, which will be target-agnostic. The back-ends then can take that common form and turn it into target-specific output. We can't use something like LLVM though as we are not simply creating a language compiler: we are creating a framework compiler. We can't just compiler AS3 code to JavaScript, for we need to handle rendering in a language-specific fashion. JavaScript for example will likely need skin "classes" written directly in JavaScript that need to be stitched in to the output by the JavaScript back-end. > 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. I think you are wrong. SWC's are just SWF's wrapped up in a ZIP file. They are target-specific and thus next-to useless to a multi-target compiler solution. If people really want Goshawk to output SWC's, then it will happen. I just think it's a short-sighted idea. > Static analysis - will the new compiler be an optimizing compiler? That will depend on the back-end. Each target will likely want optimising in different ways, so it will be up to each target-specific back-end to optimise as required. The front-end of course will do no optimisation at all. David.
