# News aggregator

### Tagged instances for Aeson overlapped

### Trouble on Travis CI with recent cabal versions

### 1-to-many preprocessor in stack/Cabal builds

### PolyKind for Fixed and HasResolution from Data.Fixed

### GADTs and Exponentiated Functors

### Philip Wadler: The Ask

The Scottish Government have set a target of 10% of all trips by foot or bicycle, but less than 2% of the Scottish travel budget goes to '

*active travel*' (the buzzword for getting from one place to another minus a motor). We Walk, We Cycle, We Vote and Spokes suggest you ask your candidate to pledge the following:

To raise the share of the transport budget spent on walking and cycling to 10% over the course of the next parliament.See the pages linked above for more info, including hustings you can attend to put the question to your local candidates. A don't forget to Pedal on Parliament on 23 April 2016.

### Type-level list "elem" inference

### Gabriel Gonzalez: From mathematics to map-reduce

There's more mathematics to programming than meets the eye. This post will highlight one such connection that explains the link between map-reduce and category theory. I will then conclude with some wild speculation about what this might imply for future programming paradigms.

This post assumes that you already know Haskell and explains the mathematics behind the map-reduce using Haskell concepts and terminology. This means that this post will oversimplify some of the category theory concepts in order to embed them in Haskell, but the overall gist will still be correct.

Background (Isomorphism)In Haskell, we like to say that two types, s and t, are "isomorphic" if and only if there are two functions, fw and bw, of types

fw :: s -> tbw :: t -> s

... that are inverse of each other:

fw . bw = idbw . fw = id

We will use the symbol ≅ to denote that two types are isomorphic. So, for example, we would summarize all of the above by just writing:

s ≅ tThe fully general definition of isomorphism from category theory is actually much broader than this, but this definition will do for now.

Background (Adjoint functors)Given two functors, f and g, f is left-adjoint to g if and only if:

f a -> b ≅ a -> g bIn other words, for them to be adjoint there must be two functions, fw and bw of types:

fw :: (f a -> b) -> (a -> g b)bw :: (a -> g b) -> (f a -> b)

... such that:

fw . bw = idbw . fw = id

These "functors" are not necessarily the same as Haskell's Functor class. The category theory definition of "functor" is more general than Haskell's Functor class and we'll be taking advantage of that extra generality in the next section.

Free functorsImagine a functor named g that acted more like a type-level function that transforms one type into another type. In this case, g will be a function that erases a constraint named C. For example:

-- `g` is a *type-level* function, and `t` is a *type*g (C t => t) = t

In other words, g "forgets" the C constraint on type t. We call g a "forgetful functor".

If some other functor, f is left-adjoint to g then we say that f is the "free C" (where C is the constraint that g "forgets").

In other words, a "free C" is a functor that is left-adjoint to another functor that forgets the constraint C.

Free monoidThe list type constructor, [], is the "free Monoid"

The "free Monoid" is, by definition, a functor [] that is left-adjoint to some other functor g that deletes Monoid constraints.

When we say that g deletes Monoid constraints we mean that:

g (Monoid m => m) = m... and when we say that [] is left-adjoint to g that means that:

[] a -> b ≅ a -> g b... and the type [a] is syntactic sugar for [] a, so we can also write:

[a] -> b ≅ a -> g bNow substitute b with some type with a Monoid constraint, like this one:

b = Monoid m => mThat gives us:

[a] -> (Monoid m => m) ≅ a -> g (Monoid m => m)... and since g deletes Monoid constraints, that leaves us with:

[a] -> (Monoid m => m) ≅ a -> mThe above isomorphism in turn implies that there must be two functions, fw and bw, of types:

fw :: ([a] -> (Monoid m => m)) -> (a -> m)bw :: (a -> m) -> ([a] -> (Monoid m => m))

... and these two functions must be inverses of each other:

fw . bw = idbw . fw = id

We can pull out the Monoid constraints to the left to give us these more idiomatic types:

fw :: (Monoid m => [a] -> m)) -> (a -> m)bw :: Monoid m => ( a -> m) -> ([a] -> m)

Both of these types have "obvious" implementations:

fw :: (Monoid m => [a] -> m)) -> (a -> m)fw k x = k [x]

bw :: Monoid m => (a -> m) -> ([a] -> m)

bw k xs = mconcat (map k xs)

Now we need to prove that the fw and bw functions are inverse of each other. Here are the proofs:

-- Proof #1fw . bw

-- eta-expand

= \k -> fw (bw k)

-- eta-expand

= \k x -> fw (bw k) x

-- Definition of `fw`

= \k x -> bw k [x]

-- Definition of `bw`

= \k x -> mconcat (map k [x])

-- Definition of `map`

= \k x -> mconcat [k x]

-- Definition of `mconcat`

= \k x -> k x

-- eta-reduce

= \k -> k

-- Definition of `id`

= id

-- Proof #2

bw . fw

-- eta-expand

= \k -> bw (fw k)

-- eta-expand

= \k xs -> bw (fw k) xs

-- Definition of `bw`

= \k xs -> mconcat (map (fw k) xs)

-- eta-expand

= \k xs -> mconcat (map (\x -> fw k x) xs)

-- Definition of `fw`

= \k xs -> mconcat (map (\x -> k [x]) xs)

-- map (f . g) = map f . map g

= \k xs -> mconcat (map k (map (\x -> [x]) xs))

-- ... and then a miracle occurs ...

--

-- In all seriousness this step uses a "free theorem" which says

-- that:

--

-- forall (k :: Monoid m => [a] -> m) . mconcat . map k = k . mconcat

--

-- We haven't covered free theorems, but you can read more about them

-- here: http://ttic.uchicago.edu/~dreyer/course/papers/wadler.pdf

= \k xs -> k (mconcat (map (\x -> [x]) xs)

-- This next step is a proof by induction, which I've omitted

= \k xs -> k xs

-- eta-reduce

= \k -> k

-- Definition of `id`

= idMap reduce

Let's revisit the type and implementation of our bw function:

bw :: Monoid m => (a -> m) -> ([a] -> m)bw k xs = mconcat (map k xs)

That bw function is significant because it is a simplified form of map-reduce:

- First you "map" a function named k over the list of xs
- Then you "reduce" the list using mconcat

In other words, bw is a pure "map-reduce" function and actually already exists in Haskell's standard library as the foldMap function.

The theory of free objects predict that all other functions of interest over a free object (like the free Monoid) can be reduced to the above fundamental function. In other words, the theory indicates that we can implement all other functions over lists in terms of this very general map-reduce function. We could have predicted the importance of "map-reduce purely from the theory of "free Monoids"!

However, there are other free objects besides free Monoids. For example, there are "free Monads" and "free Categorys" and "free Applicatives" and each of them is equipped with a similarly fundamental function that we can use to express all other functions of interest. I believe that each one of these fundamental functions is a programming paradigm waiting to be discovered just like the map-reduce paradigm.

### Magnus Therning: From JSON to sum type

For a while I’ve been planning to take full ownership of the JSON serialisation and parsing in cblrepo. The recent inclusion of instances of ToJSON and FromJSON for Version pushed me to take the first step by writing my own instances for all external types.

When doing this I noticed that all examples in the aeson docs use a product

data Person = Person { name :: Text , age :: Int }whereas I had to deal with quite a few sums, e.g. VersionRange. At first I struggled a little with how to write an instance of FromJSON. After quite a bit of thinking I came up with the following, which I think is fairly nice, but I’d really like to hear what others think about it. Maybe I’ve just missed a much simpler way of implementing parseJSON:

instance FromJSON V.VersionRange where parseJSON = withObject "VersionRange" go where go o = do lv <- (o .:? "LaterVersion") >>= return . fmap V.laterVersion tv <- (o .:? "ThisVersion") >>= return . fmap V.thisVersion ev <- (o .:? "EarlierVersion") >>= return . fmap V.earlierVersion av <- (o .:? "AnyVersion") >>= \ (_::Maybe [(Int,Int)]) -> return $ Just V.anyVersion wv <- (o .:? "WildcardVersion") >>= return . fmap V.WildcardVersion uvr <- (o .:? "UnionVersionRanges") >>= return . fmap toUvr ivr <- (o .:? "IntersectVersionRanges") >>= return . fmap toIvr vrp <- (o .:? "VersionRangeParens") >>= return . fmap V.VersionRangeParens maybe (typeMismatch "VersionRange" $ Object o) return (lv <|> tv <|> ev <|> uvr <|> ivr <|> wv <|> vrp <|> av) toUvr [v0, v1] = V.unionVersionRanges v0 v1 toIvr [v0, v1] = V.intersectVersionRanges v0 v1Any and all comments and suggestions are more than welcome!

### Reducing boilerplate

### Digraphs With Text: More flexible than graphs,eager to hear from you

### Accuracy of Data.Number.Fixed

### Call for Participation: PLACES 2016

### HasCallStack - runtime costs?

### Month in Haskell Mode February 2016

### Order of Map.fromListWith

### Function that put elements in Left or Right side ofEither depending on type

### apfelmus: FRP — Video of my Talk at Bobkonf 2016

Two weeks ago, I had the pleasure of attending the BOB Konferenz 2016 in Berlin, Germany, where I gave an introductory talk on functional reactive programming (FRP) in english. The talk was videotaped and the recording is now available online. So, if you like to hear a short introduction from me on what FRP is all about, and why it’s a good idea, I invite you to have a look. Slides are available, too.

The purpose of the conference was to bring together

[…] developers, architects and builders to explore technologies beyond the mainstream and to discover the best tools available today for building software.

My favorite talks were the presentation by Andres Löh on the Servant library, which allows the specification of REST APIs in the type system and eliminates a lot of boilerplate, and the talk by Stefan Wehr on the Swift language (that new language by Apple), where he demonstrated that functional programming actually *has* already become mainstream.

### LambdaCube: Tuples as heterogeneous lists

You probably know that lists and tuples are in no way special data types in Haskell. They are basically the following ADTs (algebraic data types) with special syntax:

data List a -- syntax in type context: [a] = Nil -- syntax in expression context: [] | Cons a (List a) -- syntax in expression context: (a : as) data Tuple2 a b -- syntax in type context: (a, b) = Tuple2 a b -- syntax in expression context: (a, b) data Tuple3 a b c -- syntax in type context: (a, b, c) = Tuple3 a b c -- syntax in expression context: (a, b, c) data Tuple4 a b c d -- syntax in type context: (a, b, c, d) = Tuple4 a b c d -- syntax in expression context: (a, b, c, d) ...All right, but what exactly does that ... mean at the end? Do infinite tuples exist? Or at least, are there infinitely many tuples with different arities? In the case of GHC the answer is no, and this is very easy to demonstrate. Try to enter this tuple in ghci:

GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help Prelude> (0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0) <interactive>:2:1: A 63-tuple is too large for GHC (max size is 62) Workaround: use nested tuples or define a data typeAlthough this seems reasonable, those who strive for perfection are not satisfied. What is the right solution for this problem? What is the real problem by the way?

I consider the Tuple2, Tuple3, Tuple4, … ADT family an inferior representation of tuples because of the following reasons:

- There is this ugly … at the end with several consequences.
- This family has no proper beginning. We can define both Tuple0 and Tuple1, but one-element tuples are not yet embraced by the Haskell community.
- Tuples with different arities are not related to each other, because they are defined separately, not at once as one data family. One consequence of this is that it is not possible to write generic functions for tuples.

What would be a better representation of tuples? Heterogeneous lists, of course!

data HList :: List Type -> Type where HNil :: HList 'Nil HCons :: forall t ts . t -> HList ts -> HList ('Cons t ts)Some examples:

HNil :: HList 'Nil HCons True HNil :: HList ('Cons Bool 'Nil) HCons 3 (HCons True HNil) :: HList ('Cons Int ('Cons Bool 'Nil)The syntactic sugar for heterogeneous lists could be the same as for tuples, for example

() ==> HNil -- in expression context () ==> HList 'Nil -- in type context (3, True) ==> HCons 3 (HCons True HNil) -- in expression context (Int, Bool) ==> HList ('Cons Int ('Cons Bool 'Nil) -- in type contextWhat are the issues of representing tuples by heterogeneous lists?

- There is a thing called one-element tuple, which needs explicit syntax.
- We need some type system extensions (at least GADTs and type level lists are needed).
- The compiler backend has to be a little bit smarter to produce efficient code for tuples.
- Pattern matching on tuples is not obvious anymore.

The LambaCube 3D compiler solves the above issues the following way:

- One element tuples are denoted by ((
*element*)). - The compiler has a dependently typed core language, therefore defining and using the HList data type works out-of-the-box.
- Currently the compiler has no code generator for CPUs and it has only a limited code generator for GPUs with no support for tuples. Tuples either vanish during reduction, or they are transformed away in the shader code generator.
- Pattern matching on heterogeneous lists is restricted: when a tuple is matched, all patterns should have the same tuple arity. We’re okay with this, since this behaviour is not surprising for most programmers, and in LambdaCube 3D code tuple patterns tend to appear without alternative choices anyway.

After solving these issues, and migrating to the new representation of tuples, the built-in LambdaCube 3D library could be simplified significantly.

Some examples: previously we had repetitive, incomplete and potentially wrong functions for tuples like

type family JoinTupleType t1 t2 where JoinTupleType a () = a JoinTupleType a (b, c) = (a, b, c) JoinTupleType a (b, c, d) = (a, b, c, d) JoinTupleType a (b, c, d, e) = (a, b, c, d, e) JoinTupleType a b = (a, b) -- this is wrong if b is a 5-tuple! -- JoinTupleType a ((b)) = (a, b) -- something like this would be OK remSemantics :: ImageSemantics -> Type remSemantics = ... -- definition is not relevant now remSemantics_ :: [ImageSemantics] -> Type remSemantics_ [] = '() remSemantics_ [a] = remSemantics a -- not good enough... -- remSemantics_ [a] = '((remSemantics a)) -- something like this would be OK remSemantics_ [a, b] = '(remSemantics a, remSemantics b) remSemantics_ [a, b, c] = '(remSemantics a, remSemantics b, remSemantics c) remSemantics_ [a, b, c, d] = '(remSemantics a, remSemantics b, remSemantics c, remSemantics d) remSemantics_ [a, b, c, d, e] = '(remSemantics a, remSemantics b, remSemantics c, remSemantics d, remSemantics e)With heterogeneous lists as tuples these and similar functions shrank considerably:

type family JoinTupleType a b where JoinTupleType x (HList xs) = HList '(x: xs) remSemantics_ :: [ImageSemantics] -> Type remSemantics_ ts = 'HList (map remSemantics ts)By the way, with heterogeneous lists it was also easier to add row polymorphism (one solution for generic records) to the type system, but that is a different story.

The pattern matching issue deserves a bit more detail. Why is it a good idea to restrict pattern matching for heterogeneous lists? Well, consider the following function with *no type annotation*:

Of course we expect the compiler to infer the type of swap. On the other hand, if tuples are heterogeneous lists, the following function is also typeable:

f (_, _) = 2 f (_, _, _) = 3 f _ = 0It seems that type inference is not feasible for heterogeneous lists in general. For LambdaCube 3D we settled with above mentioned restriction in order to retain type inference. It seems feasible to create a system that allows the definition of f *with a type annotation*, but this would not buy much for the users of LambdaCube 3D so we didn’t go for it.

I have found a few implementations of heterogeneous lists in Haskell, Idris and Agda. So far I have not found a language where tuples are represented with heterogeneous lists, neither a language with special syntax for heterogeneous lists.

- HVect in reroute package is the same as HList.
- HVect in hvect package is a strict variant of HList.
- Tuples in Idris are different: (x, y, z) is a synonym for (x, (y, z)). On the other hand, HVect in the standard library is similar to HList. The difference is that the type level list is indexed by its length. I have found this discussion about whether tuples could be represented with HVect. It seems that efficient code generation is the difficult part.
- I have found an implementation of HList and HVec in Agda. However, I also found this discussion about size problems, so it is not so convenient to use them. We don’t have such issues because we use type-in-type.
- https://wiki.haskell.org/Heterogenous_collections gives a summary about implementing heterogeneous collections in Haskell. Heterogeneous lists are at the bottom (see next item).
- Strongly typed heterogeneous collections by Oleg Kiselyov has a more complicated implementation of heterogeneous lists in Haskell using less type system extensions.

To sum it up, in the case of LambdaCube 3D, representing tuples as heterogeneous lists has no drawback and at the same time the base library (which provides the OpenGL binding) became more complete, shorter and more correct. We definitely consider switching to this representation an overall win.