Reflecting on Haskell in 2015
It’s been quite a year in the language we know and love called Haskell both for me personally and as a community. Personally I’ve been fortunate enough to write quite a bit of Haskell professionally. It’s an interesting experience and changed my perspective quite a bit on the state of our profession.
For the language and community side there’s been quite a bit of technical progress; probably not as much as some of us hope for, but Haskell is not a language of rapid hype, it’s a multi-decade engineering program. Avoiding success at all costs takes time and learning to accept the “long game” has been something I’ve come to accept with Haskell. Nevertheless I like to reflect on what’s changed and what I think will matter in 2016.
GHC
The Glorious Haskell Compiler 7.10 arrived in March and brought with it several major new features, as well as an abundance of bug fixes, changes to the backend compiler, code generation, and linker.
The The Applicative Monad Proposal landed finally making Applicative a superclass of Monad.
The Burning Bridges Proposal landed which reexported many of the monomorphic traversal functions found in the Prelude in favor of their polymorphic Traversable equivalents. There was much debate.
GHC 8.0 has several large changes that are in the works:
The long awaited Overload Record Fields extension will likely land and address some of the issues found in the old record system with overloaded selector names.
For example given the two records with identical accessors.
data S = MkS { x :: Int }
deriving Show
data T = MkT { x :: Bool, y :: Bool -> Bool, tField :: Bool }The following program will typecheck since the accessors are unambiguous at their call sites.
b = s { x = 3 } :: S
c = (t :: T) { x = False }This doesn’t quite add first class records to the language yet, so code like the following polymorphic update of a field “x” can’t exist. There are some interesting proposals on the board about solutions to this though.
-- hypothetical
b :: r { x :: Int } -> Int
b r = x rThe largest change pending is a particularly ambitious program to graft some features of dependent types onto Haskell. The Kind equalities patch pending in 8.0 at makes the type system (from values up) fully dependent, whereas before we would have to rely on particularly inelegant hacks. In GHC 7.x The type of of the kind ★ used to be the sort BOX under the old regime.
> import GHC.Exts (BOX, Constraint)
> :kind Constraint
Constraint :: BOX
> :kind BOX
BOX :: BOXUnder the new work, ★ can be now represented by the identifier Type, and the type of Type is itself.
Constraint :: *
type (*) = *
type Type = *And more importantly type-level equalities concerning types are reflexive, so a proof that t1 :: k1 ~ t2 :: k2 now proves that t1 and t2 are the same and that k1 and k2 are the same. So the two parameter dependent data type Proxy can now be represented:
data Proxy k (a :: k) = PHas the following well-typed inhabitants:
x :: Proxy * Int
x = P
y :: Proxy Bool True
y = PAll types and all constructors can be promoted with -XDataKinds (which is implied by -XTypeInType), including GADT constructors!
data TyRep1 :: * -> * where
TyInt1 :: TyRep1 Int
TyBool1 :: TyRep1 Bool
data TyRep :: k -> * where
TyInt :: TyRep Int
TyBool :: TyRep Bool
TyMaybe :: TyRep Maybe
TyApp :: TyRep a -> TyRep b -> TyRep (a b)
zero1 :: forall a. TyRep1 a -> a
zero1 TyInt1 = 0
zero1 TyBool1 = FalseAnd type classes and families can be indexed by kinds now.
data Proxy a
class C t where
f :: Proxy (a :: t)
instance C Type where
f = undefinedStack
Stack is an supplement to the Cabal build system, released by FPComplete, which greatly simplifies package installation and dependency resolution. I was particularly skeptical about yet another solution to packaging, but it has since become a regular part of my Haskell workflow.
The cost to migrating and existing codebase to it is often a single command (stack init). The one additional file that is required is a stack.yaml file in addition to cabal file.
resolver: lts-3.16
packages:
- '.'
extra-deps: []
flags: {}
extra-package-dbs: []For new projects the setup process is very streamlined.
$ stack new scotty-hello-worldThe appropriate project directory is then automatically created according to the template.
├── app
│ └── Main.hs
├── LICENSE
├── scotty-hello-world.cabal
├── Setup.hs
├── src
│ └── Lib.hs
├── stack.yaml
└── test
└── Spec.hsThe equivalent cabal commands will launch the shells, compile the binary, and install; all while taking care of any dependencies involved to do these tasks.
$ stack repl
Configuring GHCi with the following packages: scotty-hello-world
GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help
[1 of 2] Compiling Lib ( scotty-hello-world/src/Lib.hs, interpreted )
[2 of 2] Compiling Main ( scotty-hello-world/app/Main.hs, interpreted )
Ok, modules loaded: Lib, Main.
*Main>$ stack build
Installing executable(s) in /.stack-work/install/x86_64-linux/lts-3.16/7.10.2/bin
Registering scotty-hello-world-0.1.0.0...
$ stack install
Copied executables to /home/sdiehl/.local/bin:
- scotty-hello-world-exeSurprising to me lately was to find how simple integrating Stack and containers solutions has become.
# stack.yaml
resolver: lts-3.16
packages:
- '.'
extra-deps: []
flags: {}
extra-package-dbs: []
image:
container:
name: example
base: hello:base
entrypoints:
- helloAnd the Docker image can be created quite simply by the following commands.
$ docker build -t hello .
$ stack image container
$ sudo docker run -t -i example hello My skeleton project template is available here.
A particularly good blog post by Tim Dysinger outlines the Haskell/Stack/Kubernetes workflow that’s used to run Stackage.
Aeson
The bread and butter (and debatably alternative base) library Aeson got much better error reporting as of aeson==0.10. Before we would often get cryptic messages concerning attoparsec internals Failed reading: satisfy.
> eitherDecode "[]" :: Either String Float
Left "Error in $: expected Float, encountered Array"> set -XDeriveGeneric
> data Point = Point { x :: Float, y :: Float} deriving (Generic, Show)
> instance FromJSON Point
> eitherDecode "{\"x\": 1}" :: Either String Point
Left "Error in $: The key \"y\" was not found"Haskell for Mac
Manuel M T Chakravarty et al. have released a new Playground environment aimed at lowering the barrier to entry in Haskell.
The platform is commercial software available on the Apple Store but is well worth the low cost for such a nicely integrated and polished introduction to the Haskell language.
Code Generation
Type-safe Runtime Code Generation
A topic of great interest to me is the Haskell interface to the LLVM code generation system, which is quickly the de-facto standard for backend intermediate languages. The llvm-general provides a phenomenal interface to generating machine code from Haskell but the underlying C++ library itself is rather brittle under the ingestion of invalid LLVM IR. Trevor McDonell et al. provided a new approach by which many semantic guarantees of the IR can be represented in the Haskell type system.
On the topic of evaluation methods there is interesting research opportunity into exploring an alternative evaluation methods for the lambda calculus under the so-called “Call-By-Push-Value” method. Surprisingly this technique has been around for 11 years but lacks an equivalent of SPJ’s seminal “stock hardware implementation” paper describing an end to end translation from CBPV to x86. This would be an interesting student project.
Web Programming
In typical Haskell tradition, Servant is a wildly different approach to designing type-safe Haskell web application interfaces. Using many of the promoted datatype techniques (DataKinds, PolyKinds, TypeOperators) it is able to statically guarantee many things that would be be pushed to runtime in other languages and make a large amount of invalid API states inexpressible. On top of that The capacity to automatically generate HTTP documentation that automatically evolves with the code is a killer feature.
I find Servant terribly interesting and will track it’s development over the next year, I think it’s certainly the shape of things to come in the Haskell web space. My only (non-technical) concern is that my applications are increasingly becoming impenetrable to those who are not deeply immersed in the lore of GHC extensions. It would be rather difficult to spin someone up on this who has not had at least several months of training about how to write Haskell and interpret the rather convoluted type-level programming error messages that often emerge.
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE OverloadedStrings #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeOperators #-}The “Hello Web App” programs of unsafe Javascript definitely has a psychological appeal to current generation of developers over a wall of impenetrable type system extensions.
var http = require('http');
var server = http.createServer(function (request, response) {
response.writeHead(200, {"Content-Type": "text/plain"});
response.end("Hello World\n");
});
server.listen(8000);This is not a critique of Servant, merely a retrospective about how far the gap between the Javascript and Haskell worlds is becoming and how much activation energy is required to cross the schism.
Numerical Programming
Dimensional finally takes many of the modern language extensions that have been present since 7.6 (type families, closed type families and promotion) and applies them to the problem of building semantically sound dimensional calculations. The example astro haskell notebooks by Doug Burke are a great example of these used to do calculations.
- Mythical Haskell Array Library
On this topic, I’m a bit more pessimistic. I don’t forsee a complete story to the NumPy/Pandas story in Haskell anytime soon. I strongly suspect that it’s simply not possible to create a library in Haskell that would draw the same kind of man-hours from scientific practitioners to see the library to fruition. Progress in the numerical Python space was hard-won and usually built on the graves of academic careers of people who become community organizers around projects like NumPy and SciPy.
There are very few solutions for which I suggest dynamic typing is a good solution, but I’m coming more and more to believe that in the domain of ad-hoc data analysis, dynamic typing hits the local maxima of usability given our current understanding of languages.
My views on this topic are unconventional within the Haskell community. In 2015 Anthony Cowley has done a great deal of groundbreaking work on exploring type framed structures using an extensible record approach that is the farthest along and shows the most promise.
Javascript
JavaScript, the language, has some issues that make working with it inconvenient and make developing software harder.
The entire Javascript “phenomenon” is well described in Alan Kay’s talk on the results of “incremental problem solving” and the programming pop culture. Nevertheless JS exists, has universal browser support and is at least retargetable from more sensible languages.
Elm is another purely functional Javascript tranpiler, it uses Haskell like syntax but is semantically is closer to early ML dialects. As of yet, there is no rich polymorphism or higher-kinded types. As such a whole family of the usual functional constructions (monoids, functors, applicatives, monads) are inexpressible. In 2016 when the languages evolves a modern type system I will give it another look. At the moment it is hard to say much about Elm.
Purescript has evolved into a very sensible transpiling solution in 2015, with a robust compiler and well structured set of base packages. The type system is superset of Haskell 2010 and expressive enough that the full set of common functional programming idioms are expressible.
class Functor f where
map :: forall a b. (a -> b) -> f a -> f b
class (Functor f) <= Apply f where
apply :: forall a b. f (a -> b) -> f a -> f b
class (Apply f) <= Applicative f where
pure :: forall a. a -> f a
class (Applicative m, Bind m) <= Monad mBeyond the Haskell scope, Purescript adds first class records and row polymorphism.
point2D = { x: 3, y: 4 }
point3D = { x: 3, y: 4, z: 5 }
distance :: { x :: Number, y :: Number } -> Number
distance point = sqrt(point.x^2 + point.y^2)Inspired by Daan Leijen’s “Programming with Row-polymorphic Effect Types”, Purescript uses a fine grained effect tracking system based on extensible rows. For instance the following two functions print and random have different effects during evaluation that are manifest explicitly in their type signature as a record inside of Eff.
random :: forall eff1. Eff (random :: RANDOM | eff1) Number
print :: forall eff2. (Show a) => a -> Eff (console :: CONSOLE | eff2) UnitWhen composed inside of the Eff monad multiple types of native effect can be interleaved into the same computation.
main :: Eff (console :: CONSOLE, random :: RANDOM) Unit
main = do
n <- random
print nThe code generation is fairly natural mapping of Haskell lambda to Javascript functions, delegation to underlying Javascript builtins for primitive operations, and the usual dictionary passing translation for typeclasses.
var $dollar = function (f) {
return function (x) {
return f(x);
};
};var show = function (dict) {
return dict.show;
};
var showNumber = new Show($foreign.showNumberImpl);
var showBoolean = new Show(function (_35) {
if (_35) {
return "true";
};
if (!_35) {
return "false";
};
throw new Error("...");
});There are a variety of bindings to external Javascript DOM libraries including React. Until the browser becomes targetable in a way that doesn’t involve transpiling source code, Purescript is as state of the art as it gets.
Editor Integration
Vim integration with Haskell has never been easier and a lot of the problems around ghc-mod and syntax highlighting have been packaged up and managed by stack now by the haskell-vim-now package. This is markedly improved from when I last wrote about vim and Haskell in 2013.
With the advent of type holes (at both the value and type level now) there exists are an interesting set of opportunities for providing Agda-like editor integration that is syntax and type aware. Specifically case expansion is a much loved feature that is still missing from our current ghc-mod tooling. Mote is an exploration of such ideas.
The Haskell IDE Engine is a community effort to provide a universal IDE interface that abstracts over the common functionality needed to build future tooling.
While this project is exciting, is a bit concerning to me how large this project has grown an enormous number of dependencies including and is probably going to end up as a very heavy library and not a lightweight ghc-mod abstraction anytime soon.
SQL
In the past SQL has been a particularly sore spot in the Haskell ecosystem, although typically the low-level bindings are present the problem of building a easy to use, type-safe, database-agnostic, language-integrated query system that maps to Haskell data structures has been ongoing. As of 2015 there are several new offerings for high level bindings, most of which offer an interesting new perspective on type-safe query generation. Uniquely Opaleye does not fall back on TemplateHaskell, and although not database agnostic, is closest to what I imagine the ideal solution would be.
I have yet to encounter a set of abstractions that brings the ideas of Philip Wadler’s A Practical Theory of Language-Integrated Query to fruition in Haskell. There is much work in this space on both the engineering and research side; yet I’m quite confident with some changes that are coming in GHC 8.0 that this will converge on a nice tight solution.
Programming Languages
Several new experimental languages have emerged that are looking into some radically different ideas about the way we structure programs. Not surprisingly many of them are bootstrapped on top of Haskell. It’s increasingly becoming simpler to build language prototypes as many of the component pieces are being abstracted out into libraries.
For those who are asking, I am continuing to write the proto functional compiler tutorial and will continue to do so in 2016. Technical writing is just a very thankless and time-consuming process.
Dependent Types
Although technically not a recent development, Idris has seen a lot of work in 2015. Idris is very promising foray into the next generation of dependently typed languages that actually aims for a full end-to-end compiler. Here is the clearest preview of what functional programming will look like in 2025.
That said, for the work that I do on a daily basis I’m a bit reserved about the offerings of dependently typed languages; having spent a fair bit of time investigating possible use cases for dependently typed numerical programming. This year may be the one that changes my mind on this, but for the moment dependent types don’t quite yet offer the same power to weight ratio as my usual System-F and ML derivative languages do. The primary criterion I would use for considering the next generation of dependently typed languages is when the first self-hosting optimizing compiler emerges. Until then I remain skeptical but optimistic about the advances in dependent types.
Education & Community
It was good year for the community. There were at least 3 more books written, thousands of StackOveflow answers added, and the Haskell subreddit grew by 4,000 users.
Real World Haskell and What I Wish I Knew were translated into Chinese.
There is still some active debate concerning the interplay of types, laws, and documentation. Although the overall state of library documentation has gotten uniformly better over the last year. It certainly is much better than seven years ago when understanding any bit of Haskell code was more a test of one’s academic library skills than programming.
The Haskell Exchange 2015 Park Bench discussion is a very good representation of many of the concerns around the growing community and the debates around “Haskell as stable industrial language” and “Haskell as vehicle for compiler research” that often occur.
It was a good year for Haskell! :-)