Has there ever been discussions about supporting scala ?
I assume that significant part of your java->javascript translater
could be resused, and the fact that scala lives in the JVM would
certainly help.
What kind of effort would it take ?
I don't suppose there is an existing scala -> java source translator?
On Oct 2, 2009 7:04 AM, "John Tamplin" <j...@google.com> wrote:
2009/10/1 Maxime Lévesque <maxime....@gmail.com>
Has there ever been discussions about supporting scala ?
There have been some water cooler discussions about it, but it seemed like there were too many tasks left to do to make Java-based GWT everything we want it to be to undertake such a project.
People have used Scala on the server with App Engine, if that is of interest.
> > I assume that significant part of your java->javascript translater > could be resused, and th...
That would help for Development Mode (previously called Hosted Mode), but doesn't really matter for compiling.
> > What kind of effort would it take ?
We already build our own Java AST from the JDT AST, so the primary things would be:--
- wire up a Scala compiler
- maybe have to do something for Java interop since we wouldn't necessarily have class files for dependencies at the time of compilation
- generate AST nodes from the Scala compiler
- update code generation passes to account for new AST nodes or new uses of existing ones
- probably minor modifications to Development Mode to know how to generate bytecode on demand for Scala
John A. Tamplin
Software Engineer (GWT), Google
--~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-To...
It might be worth it to make scalac -> decompiler -> gwtc a supported
option, just to find out how much interest there really is in Scala ->
JS. If there's only three people in the world who want Scala -> JS,
it's really up to Lex if he wants to spend his lunches supporting
them. On the other hand, there might be enough people interested in
Scala -> JS that it's worth putting a hold on the Java -> JS polish to
get proper support for Scala working RSN.
Just a thought.
Ian
I think any interested party ought to be able to try the decompiler route and see what happens. God knows how weird it might look, but I see no obvious reason that it shouldn't work. Takers?
The main hurdle remains that the compiler works on source and not
bytecode, was there not a plan to change this sometime in the future.
If it worked on bytecode one could use any language as it would not
matter. Fir the moment it's too late got that now, unless some dies
the work of building the ast from bytecode instead of source.
Regarding manpower, I spent a month or two spending 20% time on this,
following all of the threads discussed in this email. From where
things are, I would estimate a 3-week full time effort to get a basic
version working that, for example, translated function literals the
same way that inner classes are translated. Getting structural method
calls to work would take a little while longer, but they aren't used
that much in most Scala code. Getting Scala function literals
translated to JavaScript function literals would require updating
GWT's IR analogous to what Max describes, and nobody has really
thought through a specific plan for that.
If anyone wants to work on this, I can give all the relevant Scala and
GWT pointers. Just let me know. It would involve writing some Scala
code, but would not require any deep knowledge of compilers.
Let me now update all the subthreads I see on here with what I found.
Please ping if I have overlooked something.
Decompilation does not work on Scala. I tried all the ones I could
get my hands on, and they all fail. It's been about a year, so if
anyone knows of a decompiler breakthrough in that time, it might be
possible now. However, it would take large changes. The decompiled
output I looked at was fine for 90% of the code, but the remaining 10%
included some really big problems that needed solving.
Generating Java source code from scalac might be possible, but it's
terribly difficult. Java source code does not want to be a target
language. Java rejects all kinds of code that are logical but that
wouldn't make sense to write by hand. When I started on this path, I
enumerated all the problems I knew of and found a solution to all of
them. However, along the way, more of them popped up. None of them
were ever fatal by themselves, but there are a bunch of them.
A better tactic would be to define a modified Java source language
that does not have the restrictions. It would be pretty much the same
as Java, but with a few changes. A partial list of changes would be:
1. There is no rule in constructors about calling the super()
constructor as the syntactically first thing in a constructor.
2. There is a comma operator expression just like in JavaScript.
3. Any expression can be used in an expression statement, even useless
things like literals.
4. The types would all be Java erased types.
5. Probably imports would be removed.
6. Overloading and overriding would be as in Java byte code, including
override on return type.
7. That probably implies that method calls are also as in Java byte
code, and specify the full method signature.
This plan has the huge advantage that everything in the chain is under
our control. The Scala compiler could generate this language, and GWT
could read it.
Also, per John's comments about decompiling Java, note that we could
plan to update this language to support more source languages than
just Java. It should be much easier for them to emit what they mean
than for GWT to reverse engineer what their bytecode intended.
Lex Spoon
This plan has the huge advantage that everything in the chain is under
our control. The Scala compiler could generate this language, and GWT
could read it.
Also, per John's comments about decompiling Java, note that we could
plan to update this language to support more source languages than
just Java. It should be much easier for them to emit what they mean
than for GWT to reverse engineer what their bytecode intended.
Parsing isn't enough. It would also be necessary to type check, so
that the meaning of the ASTs can be understand. After that, it would
be necessary to desugar the Scala ASTs down into Java equivalents.
That adds up to the bulk of a Scala compiler. Especially the type
checking part would take a lot of time to reimplement.
The next best thing would be to call into the existing Scala compiler.
However, doing it that way means that we have to figure out a way to
supply people with compatible versions of the GWT compiler and Scala
compiler. If we don't come up with a stable API between the two code
bases, then we'll have to figure out a way to supply users binaries of
each language that work well together. We can do that, but it will
mean people have an extra constraint when they choose which version of
GWT and which version of Scala they want to use. Coming up with an
API looks better.
The text format would essentially be such an API. It is unlikely to
change much over time, because both code bases are tracking Java's
glacial motion. Further, it shouldn't be too time consuming to
develop, because it's only use would be to make two known code bases
be able to talk to each other.
Lex
I was thinking it would be a text format, but it could be a binary
format if that looks easier.
Lex