from Scala to Scala--

This is very interesting, thanks for sharing this work, Miguel!

I was particularly intrigued by the statement that it's thinkable that
this would lead to a java source output for Scala. I know it is hard
to get there, but if we could achieve this, it would be extremely
interesting. First, it would enable Scala to run with tools like GWT
which take Java source as input. Second, it would give reassurance to
managers: "If your Scala experiment does not work out (politically or
technically), no problem, just translate the sources back to Java".

Cheers

* is translates Java to Scala. I wonder if it's possible to go the
other way.

* http://github.com/paulp/scalify

—Mohamed

On 04/01/10 20:09, martin odersky wrote:
> This is very interesting, thanks for sharing this work, Miguel!
>
> I was particularly intrigued by the statement that it's thinkable that
> this would lead to a java source output for Scala. I know it is hard
> to get there, but if we could achieve this, it would be extremely
> interesting. First, it would enable Scala to run with tools like GWT
> which take Java source as input. Second, it would give reassurance to
> managers: "If your Scala experiment does not work out (politically or
> technically), no problem, just translate the sources back to Java".
>
> Cheers
>
> -- Martin
>
>
>
> On Mon, Jan 4, 2010 at 5:53 PM, Miguel Garcia wrote:
>
>> Another tool for the Scala community. Let me explain.
>>
>> The Scala compiler processes ASTs over a number of phases, where each phase
>> recasts ASTs into a simpler language fragment. The last phase where the
>> intermediate language is still a Scala subset is CleanUp, afterwards ICode
>> is used. The attached DRAFT notes explore the design of a compiler plugin to
>> rephrase (in terms of Scala textual syntax) the ASTs at the end of each
>> non-ICode phase, in a manner that would allow using a Scala IDE on the
>> resulting source files. For the most-reduced ASTs (at the end of the CleanUp
>> phase) we dub the resulting syntax Scala--
>>
>> Advantages?
>>
>> (1) provides insight into the transformations performed by each phase, by
>> relying on the IDE facilities for code navigation and summarization (the
>> user-friendliness of -Xprint: and -Yshow-trees notwithstanding :-)
>>
>> (2) from an instructional point of view, we also want to finally understand
>> what all those AST shapes actually mean (e.g., the interplay between
>> LabelDef and Apply).
>>
>> (3) provides yet another mechanism to check whether intermediate ASTs are
>> well-formed (in a way more complete manner than with -Ycheck)
>>
>>
>> The first goal is not only relevant for compiler hackers, but for most Scala
>> users. Otherwise, how can you know what AST rewritings a given compiler
>> plugin performs? (e.g., to handle Continuations). Or will you inspect the
>> resulting bytecode instead? ;-)
>>
>>
>>
>> And there's more! Just take a look at the attached report and the sources
>> (which are work in progress) available from
>> http://www.sts.tu-harburg.de/people/mi.garcia/ScalaCompilerCorner/code/s...
>>
>>
>>
>> Miguel
>>
>>
>>