- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
was someone generating .java already?
Fri, 2010-01-08, 09:46
Hi,
"Just for fun" I was looking at what it takes to add a new backend to the
compiler, to generate .java instead of .class files (as per my previous
post).
I thought, if it's ever going to work, a first step consists in generating a
class hierarchy with mostly method bodies, yet prompting no red squiggles.
In the code responsible for that (at GenJVM.scala, method addInnerClasses) I
found the following comment:
// sort them so inner classes succeed their enclosing class
// to satisfy the Eclipse Java compiler
Wait a minute, was someone serializing .java files already? ;-)
Fri, 2010-01-08, 10:17
#2
Re: was someone generating .java already?
> http://lampsvn.epfl.ch/trac/scala/browser/scala/branches/jvm-src
I see what you mean,
http://lampsvn.epfl.ch/trac/scala/browser/scala/branches/jvm-src/src/com...
I'll look into that.
Miguel
Fri, 2010-01-08, 10:27
#3
Re: was someone generating .java already?
While we're talking about generating Java, I still believe that getting that
translator right would be *way* easier if the generation of "Scala--" was
working (because that's the input to a future Java generator). In fact,
having the capability to print syntax trees at the end of each phase *in
Scala syntax* (IDE consumable) would help wonders with scalac debugging, in
the form of automated regression tests. It's also reasonable to expect such
facility to enable (for Scala) things like:
Automated testing of refactoring engines, http://mir.cs.illinois.edu/astgen/
In closing, please please someone make production-ready :-) the prototype to
generate Scala-- sketched at
http://www.sts.tu-harburg.de/people/mi.garcia/ScalaCompilerCorner/ScalaM...
Miguel
Fri, 2010-01-08, 10:47
#4
Re: was someone generating .java already?
On Fri, Jan 8, 2010 at 9:46 AM, Miguel Garcia <miguel.garcia@tuhh.de> wrote:
Hi,
"Just for fun" I was looking at what it takes to add a new backend to the compiler, to generate .java instead of .class files (as per my previous post).
I thought, if it's ever going to work, a first step consists in generating a class hierarchy with mostly method bodies, yet prompting no red squiggles. In the code responsible for that (at GenJVM.scala, method addInnerClasses) I found the following comment:
// sort them so inner classes succeed their enclosing class
// to satisfy the Eclipse Java compiler
Wait a minute, was someone serializing .java files already? ;-)
No, at least that's not the meaning of that comment. The Eclipse javac was expecting a certain order when reading the InnerClasses attribute, so scalac was modified to allow Eclipse Java projects to use scala binaries.
iulian
Miguel
http://www.sts.tu-harburg.de/people/mi.garcia
--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais
Fri, 2010-01-08, 12:07
#5
previous work on Scala to Java translator
Fri, 2010-01-08, 15:37
#6
role of inline, closelim, and dce in terms of Java
Hi, As part of the quest to estimate what it takes to generate .java from information produced during *both* of cleanup and icode, I've reached the point where I can: (a) deep dive into inline, closelim, and dce;
or (b) ask Iulian a question. Guess what.
Context for my question: as part of a previous thread [1], some difficulties were mentioned: ---- begin quote ----
... there are some bytecode idioms that can't be translated
easily to Java source. Right now we know of
(and have at least partial solutions for) three problems:
blocks as part of expressions that are executed with non-empty stacks.
object initialization, where outer pointers have to be assigned
before calling the superclass
overrides in parametric classes require sometimes bridge methods
which can lead to double definitions when seen as Java source.
---- end quote ---- (BTW, I have no idea what examples for the above might look like). My real question however is about inline, closelim, and dce. Part 1: Is it possible to generate valid (if less efficient) bytecode by skipping altogether those phases? And part 2: If not, well, then I guess it's not as easy as I thought :-)
regards, Miguel
http://www.sts.tu-harburg.de/people/mi.garcia
[1] http://thread.gmane.org/gmane.comp.lang.scala/4129/focus=4132
Fri, 2010-01-08, 16:27
#7
Re: role of inline, closelim, and dce in terms of Java
On Fri, Jan 8, 2010 at 3:32 PM, Miguel Garcia <miguel.garcia@tuhh.de> wrote:
Hi, My real question however is about inline, closelim, and dce. Part 1: Is it possible to generate valid (if less efficient) bytecode by skipping altogether those phases? And part 2: If not, well, then I guess it's not as easy as I thought :-)
Yes, in fact these phases are not run unless '-optimise' is given. My guess is that it would be more appropriate to do this translation on the AST than icode. I'm not sure if this was mentioned before, but another tricky point is recovering control flow: while loops are translated to labels and applies, and the pattern matcher sometimes uses forward jumps.
iulian
regards, Miguel
http://www.sts.tu-harburg.de/people/mi.garcia
[1] http://thread.gmane.org/gmane.comp.lang.scala/4129/focus=4132
--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais
On Fri, Jan 8, 2010 at 8:46 AM, Miguel Garcia wrote:
> Wait a minute, was someone serializing .java files already? ;-)
It hasn't been touched for a while, but have you seen the following?
http://lampsvn.epfl.ch/trac/scala/browser/scala/branches/jvm-src
Ismael