On 2009-12-03, at 09:01, Rami Ojares / AMG Oy wrote: > > > The swf9/10 back-end walks the AST transforming the "js2" to as3 and > > unparses it. That unparser knows the rules about splitting classes > > into files for the flex compiler. > > This is where I am a bit confused. > What does it mean that as3 files need to be unparsed to files for the flex > compiler?
For DHTML, we just emit one giant js1 file. For swf9/10, the Flex compiler requires each class to be in a separate file, so that's what the swf9/10 back-end does (and then it calls the Flex compiler, with appropriate parameters, to create the final swf output). > Anyway I think we should modularize laszlo more in the future. > > I do think that all the compilation steps are very useful at the moment. > 1) xml (lzx) -> > 2) js2 (lzs) -> > 3) runtime specific language (dthml-js1.5, as2, as3 ...) -> > 4) optimized version of the runtime language (compressed js file or swf file) > > According to you swf8 skips step 3 (or rather it's step 3 language is already > in binary format that the peephole optimizer then optimizes. Correct. It generates directly from the AST. > But in the future when swf8 is dropped this model holds. > > So what do I mean with modularization... > > 1) Step 2 language should be formalized. So much so that one could develop > with step 2 language only and skip step 1 language if he so pleases. Or he > could develop parts in step 1 language, compile them to step 2 language, > continue developing in it some more and then proceed to further levels. Except that we haven't written a formal spec for 'lzs' (because we hoped it was going to be written by ECMA :), this is already the case. The LFC (runtime) is written in this language. There are some missing pieces to this language: . There needs to be a way in this language to write a class that implements an LZX <tag> more automatically (right now, there is some "boilerplate" that you just have to know to write -- usually you can figure it out by prototyping your class in LZX and looking at the intermediate output of the compiler using `lzc -S`) . There needs to be a way in this language to write constraints, handlers, setters, etc. These are all done by hand, by convention right now. > 2) Level 3 languages are already formalized and documented by the parties > that make and maintain the runtimes. But laszlo compiler should be able to > compile stage 2 language to stage 3 language that is human readable and > maintains the componentization of the stage 2 (and stage 1) In debug mode the compiler retains the source file/line information in the intermediate and output files. > 3) This way one could develop his application, compile it to as3, take it > then to some flex dev environment, develop it some more and use stage 4 > compiler to create the executable. You can do this right now, although you would have to really understand the conventions that are used to transform lzs to as3. The compiler leaves the as3 files around for debugging. We could add another option to `lzc` to put the files in a particular place, rather than just /tmp. > Now the stage 2 language would be the real laszlo language lzs-js2. > Laszlo XML would be a higher level language that can be translated to > lzs-js2. Components are developed using either one of the languages. Again, this is all true today (see for instance the drawview component). We just don't have a formal definition of lzs. > Services and apis are defined in lzs-js2 because there are no method calls in > pure xml are there? Not sure what you are saying here. I think you are getting at the fact that LZX is a declarative language, whereas you need Javascript (lzs) for functional effects. > So laszlo xml would be like a useful tool on top of lzs-js2 just like there > are libraries in java who take xml gui definitions and translated them in to > java swing code. Yes, that is one way of characterizing the language. LZX is declarative, mostly aimed at specifying layout; Javascript is procedural, mostly aimed at specifying actions. > There used to be some discussion between withington and jamesr what is ment > by "userspace" (and I quess the counterpart is kernelspace). > > I would say that the userspace is the lzs-js2 language and the apis it > provides. Everything else is the implementation. Stuff that may change > without others knowing as long as it keeps up the promise made by the > language and it's api's. What I meant in that discussion is that while the source is open, and you can call any API you like, there are 'public' API's that every effort is made to maintain, and there are 'private' API's that, while not changed willy-nilly, are changed as necessary to create the most useful implementation. Sometimes the line between these is blurred by being open source, sometimes it is just due to limited resources and/or insufficient documentation. > I don't really mean that someone would develop the same application on more > than one level. But one could develop separate libraries on all 3 levels. And > one might debug the same application on all 3 levels (actually on all 4 > levels.) Many of our developers are already doing this. The `passthrough` concept is entirely intended to let you directly access the underlying platform, and we have made every effort to make it possible to add platform-native functionality to an LZX application. > This fantasy was caused by fantasies about developing everything in > javascript (a dream that sounds rather alien and awkward to my ears :) We like to develop in "the best tool for the job". So, LZX when you are doing UI and layout, Javascript for procedural, etc. I'm sure there are some fancy OMG Web 2.0 diagrams you could draw showing our multi-tiered approach to business logic... but I leave that to marketing. :)
