<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; ">These are interesting questions: what it would take to support different languages on the OpenLaszlo platform, and what it would take to add type and interface declarations. Fortunately, the second doesn't depend on the first.<DIV><BR class="khtml-block-placeholder"></DIV><DIV>(There's a third question of whether languages that require explicit typing are better or worse, to which the answer is clearly some cross between "different strokes for different folks" and "it depends".)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><B style=""><I><SPAN class="Apple-style-span" style="text-decoration: underline;">Target Language</SPAN></I></B></DIV><DIV><SPAN class="Apple-style-span">The OpenLaszlo platform is targeted first at the Flash Player, and second at browsers (although this latter target has not been realized). It consists of a compiler, and a set of runtime library code and components. It does <I>not</I> include a virtual machine or other interpreter; it relies upon the interpretation services of its execution engine. In both the Flash Player and browsers, that execution engine executes JavaScript. In the case of the Flash Player, this because the bytecode set includes single bytecodes that implement the semantics of common JavaScript operations (such as function call, method call, and comparison, array, and concatenation operators with JavaScript semantics). In the case of browsers, the execution engine executes JavaScript source code itself (after an internal step of compiling it to browser-specific bytecode in some cases --- but there is not a public API for a web site to download files that use this bytecode).</SPAN></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>It would be possible to compile other languages, such as Java, Python, or Ruby, into Flash bytecode, and it would be possible to compile them into JavaScript source code that linked against JavaScript support libraries. This, in fact, is similar to the strategy used by JVM implementations of these languages, such as Rhino, Jython, and JRuby. The problem in doing this is performance. One operation in JavaScript typically compiles to one bytecode in a swf file, and runtime execution speed is already challenging. Compiling operations such as method calls or equality comparisons to the many bytecodes that would be necessary to implement Java, Python, or Ruby semantics would not be practical. In JVM land, Rhino and Jython are orders of magnitude slower than Java. This is often acceptable because, first, the JVM is orders of magnitude faster than the Flash bytecode interpreter; second, because these scripting languages are not used to implement the inner loop of an interactive graphical application. (Where Python or Ruby are used to implement graphical applications, it's often using the C interpreters for these languages, and independently of this it's generally with a toolkit that is implemented directly in the JVM or in C, such as AWT or Swing in the case of Jython/JRuby, or such as Qt, GTK, or Cocoa in the case of CPython/CRuby.)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><SPAN class="Apple-style-span" style="text-decoration: underline;"><B><I>Explicit Typing</I></B></SPAN></DIV><DIV>However, you don't actually need another language to get explicit typing (type declarations in source code). The JavaScript 2.0 proposal already defines type declarations, class, and interface definitions. You just need some work on the compiler.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>There are these stages to the use of type declarations (after anger, bargaining, and grief :-):</DIV><DIV>1. Syntactic declarations. Being able to write 'function f(a: Integer, b: String): Boolean' instead of simply 'function f(a, b)'.</DIV><DIV>2. Compile-time checking. Getting a compiler warning for 'f(1, 2)' in the case above (because 2 isn't a string).</DIV><DIV>3. Runtime checking. Getting a runtime warning for 'f(1, 2)', if it's used in a case where the compiler couldn't tell what 'f' named so it could warn you as in (2).</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>OpenLaszlo implements JavaScript 1.5 (aka ECMAScript 3), which doesn't have type declarations at all. It's at stage 0: no type declarations at all. (Actually there are type declarations on <attribute> elements, and there's a doc comment convention, processed by the doc tools, for annotating the types of JavaScript properties, parameters, and functions.)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>ActionScript 2.0, used in Flex, is mostly equivalent to JavaScript 2 (aka the proposal ECMAScript 4). ActionScript 2.0 adds stages 1 and 2. (My understanding is that it doesn't do 3: that this is a compiler feature only.)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Adding this to OpenLaszlo has been on the wishlist for a long time --- since way before Action 2.0 or Flex for that matter --- but we've never had the time to do it. It involves, first, a change to the JavaScript parser in $LPS_HOME/WEB-INF/server/sc/src/org/openlaszlo/sc/Parser.jjt to accept optional type declarations in its definitions of VariableStatement, FunctionDeclaration, and FormalParameterList. This would be sufficient to add the ability to declare types, although they would only be used for documentation purposes, and not checked. In other words, this would take OpenLaszlo to stage 1.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>This would also lay the groundwork for changing the code in $LPS_HOME/WEB-INF/server/sc/Compiler.py to store type information. At that point, making use of this in more and more contexts in order to provide more and more compile-time warnings could be done on an ongoing basis, in order to provide increasingly higher-quality implementations of stage (2).</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>And if I'm wrong about ActionScript supporting (3), then passing the type information to the runtime would be simple (relative to (2).</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>There's a similar story about the 'interface', 'class' and access modifiers --- except that most of the parse rules for 'class' are already present in the parser. (A preview release of OpenLaszlo in 2002(!) supported the 'class' construct by compiling it into the appropriate manipulations of the constructor's property and its prototype's properties, we just didn't have time to maintain it in the face of some gymnastics necessary to make code in <script> blocks work correctly with event callbacks and deferred instantiation.)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>The first part of this is all JavaCC hacking, and the second part is Jython hacking; it doesn't require any knowledge of Flash or the Flash runtime. Let me know if anyone's interested, and I can write up documentation for how it works now and how to do this.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Best,</DIV><DIV>Oliver</DIV></BODY></HTML>