Charles~ I think such an AST would be both useful and applicable. For example, the compiler that my company writes can emit java code which we can then send to javac. The serialization followed by parse of that code represents a non-trivial amount of our start up time. If we could go straight from our AST to a Java AST (which I imagine are not too different), we could save a lot of IO.
Also, an AST with the rought semantics of Java Bytecode (but without arbitrary limits), would be a reasonable candidate as well. Matt On 10/2/07, Charles Oliver Nutter <[EMAIL PROTECTED]> wrote: > > John Wilson wrote: > > I wonder how feasible it would be to define a standard AST as well? > > I'm thinking in terms of a set of interfaces/abstract classes which > > represent a class. Each language implementation would > > implement/subclass these to produce a concrete AST (a rather confusing > > term I'm afraid). > > Unfortunately, this ignores one key point: my Ruby-compiled code, for > example, would never be representable in anything resembling a Java AST. > In fact, it's practically impossible to decompile it even now, and I > suspect we're going to see that's the case in many other compiled > non-Java languages on the JVM. Microsoft's DLR has made attempts to have > a common AST structure (or as they call it, an abstract semantic tree), > but from what I understand only IronPython is using it, with IronRuby > forced to use the AST coming out of a YACC/Bison-based parser. A common > AST would be impressive, but I think it's probably almost impossible to > find something we call can use to represent our languages. > > Of course I'm also a little biased at this point; I've sadly gotten to > the point where I can emit sequences of 25-50 raw bytecodes and have > them work the first time, so I'm starting to lose touch with a > non-bytecode way of life :) > > - Charlie > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
