Google Summer of Code 2018
This is work in progress for the upcoming GSoC 2018
This is work in progress for the upcoming GSoC 2018
Eta has been accepted for GSoC 2018 to work with students and help them work on interesting projects to make the Eta ecosystem better. We have provided a list of project ideas on this page to provide some inspiration for students to come up with their own ideas or use the existing ones.
Students are expected to go through the ideas and be able to analyze the idea and be able to explain all the different parts of the codebase that must be modified in order to implement the idea.
Note: Students can submit one or more proposals. But only one will be selected.
On every commit to the master branch of the Eta repository, benchmarks are run to see how each change to the compiler is affecting the performance of compiled programs. The goal of this project is to generate a simple web application that allows you to travel through time and compare performance of various benchmarks.
The error messages produced by Eta can be a bit hard to read and figure out if one is not familiar with how the typechecking process works in the compiler. What we would like is for type error messages to directly give users suggestions on what the most probable mistake was in their code. This will yield a significant boost in developer productivity and make it easier for beginners to troubleshoot type errors. The goal of this project is to re-structure the typechecker in the Eta compiler to support the new error reporting mechanism mentioned above and design a heuristic for generating good suggestions to the user.
The bytecode generated by Eta is compatible with Java 7 so using Eta on Android should be possible. Currently, working with Eta on Android requires a lot of manual steps and requires coordination among different build tools. This project aims to make it easy to do Android development in Eta. This project consists of the following components:
The existing Eta Gradle Plugin should be extended to support the Android development workflow and packaging code into an APK.
Eta has experimental support for Fibers, a lightweight threading mechanism that lets the developer have control over when to yield the thread. A good test of their effectiveness is to write a non-trivial application - a web server.
Haskell already has a web server implementation called warp. The goal of this project is to re-implement Warp using Fibers. It requires that the student first implement non-blocking I/O support for Fibers and then proceed to the web server implementation.
Given the same source files, Eta does not produce the same classfiles every time those source files are provided as input. Internally, the compiler assigns a unique integer to every program entity and that integer can change every time you build your program due to various source of non-determinism. Thus, the hash of the output classfiles will change across rebuilds of the same source files, which can mean that it can cause re-builds to be inefficient in systems like Bazel.
The goal of this project is to investigate all the source of non-determinism. A lot of this work has already been done in GHC 8, so it boils down to analyzing those changes individually and incorporating them into the Eta codebase without changing the existing compilation behavior.
Eta produces classfiles that are Java 7 compatible so that we leave open the option of running on Android in the future. At the same time, the newer JVM versions have incorporated support for a new bytecode instruction called invokedynamic that effectively allows you to define custom method dispatch behavior while allowing the JVM's Just-In Time compiler (JIT) to optimize it as it normally would.
Vert.x is a popular framework for building asynchronous/reactive applications on the JVM. Integration to this library will provide access to a whole host of asynchronous libraries in the Vert.x ecosystem. The goal of this project is to adapt Eta's Fibers (see above) to support fibered, non-blocking API bindings to Vert.x libraries.
When binding to Java libraries using Eta's Foreign Function Interface (FFI) mechanism, the user needs to know the Java library well enough to decide whether the object in question is pure or impure (requires a pure or monadic return type) and to decide whether to wrap the return type in a Maybe, indicating that the result may be null. If the user fails to do either of these correctly, and doesn't go with the worst-case option of making the return type monadic and wrapped in a Maybe, strange bugs can ensue.
The goal of this project is to develop a tool that can take a Java library as input and classify each method and field's purity and nullability, so that we can feed that data into an FFI generator to automate highly precise bindings for Java libraries.
Read the student guide of GSoC. The application process is as follows:
We’ve curated resources to help you get started faster with Eta depending on your needs.
by