Although JavaScript allows rapid prototyping, I miss many of Java's features when writing flow scripts, such as strong typing and all the Eclipse features (code completion, javadoc tooltips, etc).
Yesterday's thoughts ended with the following action items to have flow written in Java :
- Hardest point : we first must have continuations in Java. Taking Brakes as a starting point, this shouldn't be that much work. I also thought about tail-call optimization (tail recursion is easy), which can partially be implemented (we can trash all local variables, but I think we need to keep the full method call chain).
- Automatic compiling classloader. Next to continuations, the niciest feature of flow script is the fast trial and error cycle : save your file, reload and see your changes. The same can be possible with a smart classloader that takes a source files directory instead of a class files directory. If the source file changes, it is recompiled a soon as someone calls ClassLoader.loadClass() on the corresponding class. We can also use some delegating proxies for the case where classes are loaded only once (e.g. Avalon container factories). Once you're satified with your class, you can deactivate the auto-compiling class loader and deploy a class file as usual.
- On-the-fly continuation enabler. This is another classloader which passes bytecode through the continuation transforming engine (first point above). Since not all classes require to be continuation-enabled, only classes implementing a particular marker interface will be transformed.
With the flow implemented in Java, does the "Interpreter" interface name still make sense as it does with Scheme or JavaScript ? It seems to me "Controller" or "ContinuationEnabledLanguage" would be more appropriate.