steele at laszlosystems.com
Sun Oct 9 18:52:47 PDT 2005
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.
(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".)
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 not 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
Player, this because the bytecode set includes single bytecodes that
function call, method call, and comparison, array, and concatenation
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).
It would be possible to compile other languages, such as Java,
Python, or Ruby, into Flash bytecode, and it would be possible to
strategy used by JVM implementations of these languages, such as
Rhino, Jython, and JRuby. The problem in doing this is performance.
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
However, you don't actually need another language to get explicit
proposal already defines type declarations, class, and interface
definitions. You just need some work on the compiler.
There are these stages to the use of type declarations (after anger,
bargaining, and grief :-):
1. Syntactic declarations. Being able to write 'function f(a:
Integer, b: String): Boolean' instead of simply 'function f(a, b)'.
2. Compile-time checking. Getting a compiler warning for 'f(1, 2)'
in the case above (because 2 isn't a string).
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).
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
parameters, and functions.)
(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.)
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
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.
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).
And if I'm wrong about ActionScript supporting (3), then passing the
type information to the runtime would be simple (relative to (2).
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.)
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Laszlo-user