Register for C◦mp◦se :: Conference 2019 tickets at Eventbrite

Time Talk

8:30am - 9:00am Registration & Breakfast

09:00am - 10:00am KEYNOTE: Making Algorithmic Music

Donya Quick Euterpea is a library for representing and creating music in the Haskell programming language. Euterpea models music as a polymorphic tree, which makes it easy to algorithmically create and manipulate musical structures at different levels of detail. This talk will introduce how to use the library to create music and will cover some basic techniques that are used in algorithmic and automated music composition. Finally, we will explore the application of these techniques to modeling jazz improvisation in a functional style, allowing for the creation of infinite improvisations that can be generated in real time.

10:15am - 11:00am Functors of the World, Unite!

Kenny Foner To save myself from hubris, I use static types. To save myself from tedium, I use type inference. Statically typed languages like Haskell would be unusably verbose if we had to write down the type for each piece of a program. Luckily, we don't have to: the compiler happily infers the types we don't annotate. Usually, we don't need to think about how it does this; we can play by an intuition that it thinks about types like we do... until it thinks something we didn't expect. By understanding more deeply how type inference works, we can more easily debug otherwise-unintuitive type errors, and further, clarify our thinking to avoid surprises in the first place. Frustratingly, many treatments of type inference are at one of two extremes: either abstract deduction rules written on paper, or complex code from the guts of a mature programming language. As I see it, neither of these are optimal for developing our intution while we program. Let's learn to see inference how the compiler sees it, by creating a typechecker for our own small programming language. A twist: we'll melt away the incidental complexity of syntax manipulation by representing our types and terms as explicit fixed points of functors. We'll build our typechecker by first making a simple, generic library for *structural unification* of traversable data types, then by instantiating it with the terms and typing rules of our particular language. In the process, we'll see how these abstractions allow us to concisely implement type inference for all sorts of terms, types, and type system features. Inference need not be abstruse or complicated—with a dash of functorality, it can be fun!

11:00am - 11:30am The anatomy of the F# tools for Visual Studio

Phillip Carter F# is a first-class language in Visual Studio with an array of features that make people more productive. But how is the tooling built? In this talk, you’ll learn just how much goes into programming language tooling, and how we do it with F# at Microsoft. By the end of the talk, you should have an idea of how to design pieces of a compiler so that accurate tooling can be built, how constraints of a language affect tooling, and some of the challenges tooling developers face.

11:30am - 12:00pm Genspio: Generating Shell Phrases In OCaml

Sebastien Mondet Genspio is a typed EDSL based on GADTs to generate shell scripts from OCaml. We provide two compilers. The standard compiler generates strict but complex POSIX shell expressions, which can be even treated as one-liners. The second compiler, generates much slower but simpler scripts targeting a subset of POSIX which aims at being portable to older and buggy interpreters which are still found in the wild. In addition, a few generic optimizations have been implemented, and the API gives access to a generic AST visitor (using standard OCaml objects). The most interesting parts of the implementation of the project are actually its testing infrastructure and its documenation. The tests aim at evaluating the portability of the generated code by running an extensive test suite with various shells and on various systems (including by providing infrastructure to try older operating systems or other architectures with Qemu). They also include larger proof-of-concept examples which create 100% generated Github repositories for useful tools which do not depend on OCaml at all, see multi-git (scripts for dealing with a few git repositories), and cosc (script to manage long-running processes using a hidden GNU-screen session). The documentation effort has also been extensive. In addition API and examples, it includes a browser-based experimentation environment; to try and modify the documented examples, see type-errors, and inspect or even download the compilation outputs. This sub-project is based on the Tyxml and react OCaml libraries, builds with js_of_ocaml , and includes a full OCaml REPL running in a "Web-worker."

12:00pm - 12:45pm Lunch



12:45pm - 01:30pm Applicative Regular Expressions using the Free Alternative

Justin Le Free Structures – including Free Monoids and Free Monads – are a great example of a tool from mathematics that have been shown to be very useful as concepts in Haskell. Free structures of all sorts give you powerful tools in program composition, implementation, and safety guarantees. This talk shows how the implementation of a ubiquitous tool in programming, the Regular Expression, becomes almost trivial to implement when using an often-overlooked free structure, the Free Alternative. Through this accessible example, we explore the specific benefits of choosing to use a free structure for our implementation over other potential methods, and take a look into the philosophy of what makes free structures (of all types) such a powerful tool for programming.

01:30pm - 02:00pm Deploying Haskell in a Python Microservice Environment: Also Robots

Jeff Ciesielski After struggling with global variables, mismatched types, and being constantly afraid to change any code for fear of runtime errors, our team decided to move a core piece of our robotics infrastructure from Python to a type safe language. After developing proofs of concept in Rust, OCaml, Crystal, Scala, and Go (and even getting close to a production candidate in Nim) an enterprising member of our team wrote a prototype in Haskell and the results were outstanding. With its emphasis on type safety, the elimination of global state, and an established library ecosystem, Haskell has been a great fit for our team. That said, our rollout wasn’t without hiccups! Once deployed we learned about space leaks and what lazy evaluation really means for continuously running software.

02:00pm - 02:30pm From Rails to Elm and Haskell

Richard Feldman When I joined NoRedInk in 2013, we had a typical Ruby on Rails web application. In 2015 we introduced Elm, a pure functional programming language for building Web UIs, and it spread like wildfire to become our primary tool for front-end programming. In 2019 we have over 300,000 lines of Elm code powering the user interface our millions of users rely on. The positive experience we had with Elm led us to seek out a pure functional language to use on the back-end, and in 2017 we introduced Haskell to our stack. This talk discusses the reasons we tried these technologies, what we hoped to get out of them compared to what we got, what went well and what didn’t, and the strategies we used to adopt them incrementally inside a mission-critical code base. Come find out what this production transition to a purely functional stack was like!

02:45pm - 03:30pm Stuck macros: deterministically interleaving macro-expansion and typechecking

Samuel Gélineau A new breed of functional programming languages is emerging: strongly-typed macro languages, such as Hackett and Typer. Those languages feature both macros, type inference, and most importantly, the combination of the two: macros which can interrogate the type inference system in order to decide which code to generate. Both languages propose to do so by interleaving macro-expansion and type-checking, but doing so naively leads to a non-deterministic outcome: the same program may be accepted by one version of the compiler and rejected by another! In this talk, I will explain what causes this non-determinism, and how allowing macros to get “stuck” could solve the problem.

03:30pm - 04:00pm Yes, IHaskell Can Do That!

Vaibhav Sagar IHaskell is a Haskell kernel for the Jupyter notebook project. As one of its most enthusiastic users, nothing frustrates me more than someone asking, "but why?". My second biggest frustration is when people ask, "so what?" This presentation is my attempt to answer both those questions once and for all. I'll demonstrate the various ways in which IHaskell makes my life better, and the many ways in which other people are using it. My hope is that after this presentation you will have a full understanding of what IHaskell can (or can't) do, an appreciation for how it fits into the Haskell ecosystem, and potentially be inspired to contribute!