And I believe that should be a reasonable proxy for what it would look like to go from any statically-typed JVM language to Javascript without the benefit of a new IR. If it doesn't suck, then maybe I'm wrong about needing a new IR. I doubt it, but I've been wrong plenty of times before :)
On Fri, Oct 2, 2009 at 11:52 AM, Joel Webber <[email protected]> wrote: > 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? > > > On Fri, Oct 2, 2009 at 11:49 AM, Ian Petersen <[email protected]> wrote: > >> >> On Fri, Oct 2, 2009 at 8:06 AM, Joel Webber <[email protected]> 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 -~----------~----~----~----~------~----~------~--~---
