if I understand, Lex is not really talking about a new syntax/text representation, but an intermediate Java AST that has none of the restrictions that Java does. The current GWT AST lifts many of these restrictions too (you can build 'illegal' code in it that compiles fine to JS, but would not work with javac if tostring'ed). The problem with using the GWT AST is that if you want to hand something simple to Groovy, or Nice, or Clojure, it doesn't separate cleanly. Ideally, you'd want to hand them a gwtast.jar with a simple, well defined set of constructors, and promise them that if they use this to generate code, it is guaranteed to compile. Essentially, you want a portable intermediate representation, and currently, Java syntax on disk doesn't have enough fidelity.
On Mon, Oct 5, 2009 at 9:23 AM, John Tamplin <[email protected]> wrote: > On Mon, Oct 5, 2009 at 12:10 PM, Lex Spoon <[email protected]> wrote: > >> 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. >> > > Why would that be easier than just parsing Scala and building an extended > GWT AST from the Scala AST? It seems like inventing a new language (even if > it is close to Java) and modifying tools on both sides to use this would be > more work. > > -- > John A. Tamplin > Software Engineer (GWT), Google > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
