Re: [scala-language] [GSoC 2016] Java source code to Scala.js IR compiler

[Sébastien Doeraene]

Hello Piotr,

Sorry for the late answer. The past week has been crazy with work and concerts.

For reusing existing parsers/typecheckers, it has been brought to my attention that the new Android tool chain [1] uses the Eclipse Java Compiler (ECJ), so that would be something to explore.

I don't really have more ideas at the moment. The expectations are that we can actually compile non-trivial Java libraries into the IR and so reuse them in Scala.js applications. But I don't expect that *any* Java code can be compiled. In particular, I have serious doubts about class initializers.

See also another discussion on the mailing list about this project at https://groups.google.com/forum/#!topic/scala-language/lPn8f4L0wkw

Cheers,

Sébastien

[1] http://tools.android.com/tech-docs/jackandjill

On Wed, Mar 9, 2016 at 9:50 PM, Piotr Moczurad <piotr.m...@gmail.com> wrote:

Hello,

I'm writing to ask about the "Java source code (or bytecode) to Scala.js IR compiler" project. I have some experience in both Scala language (and functional programming in general) and compiler design/implementation, so I thought I could be a good fit for the project.

My name is Piotr Moczurad and I'm a fourth-year CS student at AGH University of Science and Technology in Kraków and a first-year math student at the Jagiellonian University. I took part in GSoC 2014, writing some parts of Gust (GPU extensions for the Breeze Scala linalg library). I wish I had continued to develop this project, but I got involved with Haskell programming and then mathematics. On the bright side, this allowed me to improve my functional programming skills quite considerably.

I was working at a company creating image compositing software powered by our own in-house visual-textual programming language, which was a lot of fun tinkering with the compiler (I'm particularily proud of the transparent Python-Haskell bindings that I created and unfortunately cannot open-source). As far as my compiler-related experience goes, I also recently finished a BS project involving writing a simple programming language, targeting  an FPGA-based soft processor which we also designed and implemented from the scratch. It contains some possibly interesting ideas regarding generating an architecture-targeted assembly and stack-machine design.

I'd love to hear more about this project; I think I could contribute some interesting things. I would much rather go with implementing the Java-source-code-to-IR option -- reusing parsers/typechecker sounds like a good plan (I have no problem in writing my own, however the essence of the problem is, I guess, the IR generation/optimization and the time is limited). I would love to hear more about your ideas and expectations.

I'm looking forward to hearing from you!

Regards,

Piotr Moczurad

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-languag...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Naftoli Gugenheim]

Have you seen JSweet?

[Piotr Moczurad]

Hello, Sébastien,

No problem -- I've had a busy couple of weeks myself. Although I was surprised when I saw your email regarding the test project, I thought perhaps I didn't match some requirements for this years programme and lost hope :) Well, I have to get up to speed with writing the toy compiler. It's fun; as of now I can compile let bindings and do a pretty thorough typechecking (ok, it's two types in the tiny language, but I can check things like function arity and enforce the number types of arguments). I just hope I will manage to get all the "paperwork" done today.

I looked at JSweet that @nafg mentioned (https://github.com/cincheo/jsweet) and from the first look it seems like they are using Javac to parse Java code (and Javac's to represent Java AST) and it seems like a reasonable approach. They also do some additional typechecking on their own, but it's pretty straightforward. There're also some other Java parsers that we could think about using (e.g. https://github.com/javaparser/javaparser) but as long as we have valid and easy to work with Java AST it's not much of an issue. In general, JSweet could serve as a point of reference -- their compilation pipeline is Java -> TypeScript -> JS, with TypeScript being kind of similar in spirit to our IR. Jack you mention is also certainly a tool worth taking a closer look at.

I thought for a bit about compiling from bytecode (which could be nice if we wanted to compile some other JVM languages as well) but it's also much more involved and would be more of de-compilation actually. In this use case, I guess, compiling from Java AST to Scala-JS IR is a good choice and would produce satisfying results.

The timeline in this project can be relatively natural: start with basic Java constructs like arithmetic expressions, then control flow statements, then functions of primitive types, arrays, then classes/objects etc. (I have yet to better understand the problem of initializers but I guess we can find a workaround). Then we can compile Java's generics. I guess that it's only important to keep it incremental enough -- to always have a working compiler, compiling more Java constructs with every iteration.

I will fill in the proposal today and hopefully make some reasonable PR to the scalajsir-calc repo in a few days.

Regards,

Piotr

P.S.

There is this very interesting project for compiling Haskell to JS (https://github.com/ghcjs/ghcjs). It's worth checking out even though it's not Scala/Java. They do a very interesting thing of simulating the whole Haskell evaluation model in JS. It produces lots of code but they (or actually he, Luite, who is an amazing javascript-internals guru) are constantly improving the performance and people have started to use it in production.