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. On 03/10/2009, at 1:49 AM, Ian Petersen <ispet...@gmail.com> wrote: > > On Fri, Oct 2, 2009 at 8:06 AM, Joel Webber <j...@google.com> wrote: >> scalac + a decompiler ought to do the trick, roughly. But you'd >> still end up >> with a bunch of big ugly Java constructs for things like functions, >> case >> classes, pattern matching, and the like. And while I'd love to see >> what >> would happen to that code if you ran it through gwtc, I'm guessing >> it would >> be rather suboptimal relative to what you'd get if you took the >> (scala -> >> (some better IR) -> js) path. > > 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 > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
