Skip to content

Simon Peyton Jones transcript, Frege Day 2015

Ben Sima edited this page Jul 6, 2016 · 2 revisions

At the Frege Day 2015 in Basel, Switzerland, Simon Peyton Jones joined via video. Below is a compacted transcript of the 40 min conversation.

Simon Peyton Jones discussing at the Frege Day

Dierk: "You just returned from the ICFP (International Conference for Functional Programming). How is the uptake of functional programming?"

SPJ: "The interest in functional programming has been steadily growing over the last 10 years, especially in terms of conference attendance. Alongside ICFP runs the CUFP conference (commercial users of functional programming) to represent the rising importance of the topic in the industry.

A full day is dedicated to the Haskell implementor's workshop, where also approaches like GHCJS are discussed, i.e. compilers that address vastly different runtime environments. Frege, which addresses the JVM, would very well fit into that format."

Rahel: "What prevented GHC itself to target the JVM?"

SPJ: "There have been attempts to do so but there are some inherent issues: The main purpose for targeting the JVM is to take advantage of all the libraries. In order to do so, one needs to deal with polymorphism by subtyping. Combining this with the Haskell way of parametric polymorphism would mean to 'bend' the language too much. My paper "Object-oriented style overloading for Haskell" gives one take on the question, but it is pretty complicated, and there are many possible alternative approaches.

Dierk: "Do we bend the language too much, then?"

SPJ: "How do you handle the subtyping?"

Ingo: "We don't. That is: Frege has no notion of subtyping. We can still interoperate with Java, though. To this end, we have changed the FFI. It needs to be different for Java anyway. We enhanced it to cover not only functions but also types. This allows us to keep the subtyping issue isolated in the FFI. We call that 'native declarations'."

SPJ: "But then, you have to declare every single type and method that you are using, right? Isn't that too much effort?"

Ingo: "We have a tool for that. It does most of the work but, yes, it still requires some manual afterwork."

Dierk: "But it actually works better than what one might expect. First, you only have to declare it for the types and methods that you are directly using from Frege, which are usually not so many. Second, the tool really helps. I just created the Frege API for JavaFX consisting of 855 classes, a deep inheritance hierachy, and about 20'000 methods. Even that is feasible."

SPJ: "Your special way of doing the FFI for Java sounds very interesting. You should report your experiences to the Haskell implementor's workshop at next year's ICFP."

Ingo: "We would love to. There is even more that might be interesting to the Haskell community: type-bound namespaces for example and updating records in a way that eliminates the need for lenses - at least for simple use cases."

SPJ: "Yes, there is some discussion about these issues in the community. You have the benefit that you are starting something new whereas we have to consider backwards compatibility ... Regarding compatibility: I read your 'differences to Haskell' page. A lot of those look insubstantial."

Ingo: "Yes, many of them are there for historic reasons. One big topic of today's Frege day is our roadmap: how we further evolve the language. Overcoming the easy-to-resolve differences will be an important point."

SPJ: "It would be very good news if Frege compiled any 'vanilla' Haskell source code unmodified to the JVM. It is such a commercially important platform. The CUFP has tutorials to teach real-world functional programming and a Frege tutorial would fit very well into this lineup."

Dierk: "Do you have any final words for us?"

SPJ: "It is good to see the Haskell community growing and Frege extends its reach to the Java platform. You are on the way to become 'the JVM Haskell' and you should make sure that this reflected in your name and in the way that you position your language. This will lead to even more adoption, and would be good for the Haskell community, too."

Clone this wiki locally