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

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.

W dniu wtorek, 15 marca 2016 11:36:42 UTC+1 użytkownik Sébastien Doeraene 
napisał:
>
> 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 <[email protected] 
> <javascript:>> 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 [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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 [email protected].
For more options, visit https://groups.google.com/d/optout.