Functional Stuff

haskell, functional programming and such

Read this first

Monads are not special

  • Monads are not fundamental to computation.
  • Monads are but one type of structure that can be described in Haskell (others include groups, monoids, semilattices and posets).
  • The IO constructor and its monadic interface allow embedding of imperative programs in Haskell.
  • Whenever we ask ourselves if there is anything special about IO, we really should be asking if there is anything special about imperative programming.
  • Imperative programming is mainly of historical interest
  • It is widely known that imperative programming does not scale.
  • The future of programming will probably not be imperative.
  • We should move away from relying on the IO constructor in Haskell.

Further reading

  • Imperative functional programming (SPJ and Wadler, 1992)
  • https://wiki.haskell.org/What_a_Monad_is_not
  • http://conal.net/blog/posts/the-c-language-is-purely-functional

Continue reading →


Deprecating ‘data'

Summary: Generic programming should be based on representational equality. We can obtain this by reformulating “data” in terms of “newtype”: manually or (tentatively) with compiler support

Background

In modern Haskell we often seek to derive instances, meaning to have the compiler generate them for us, as opposed to writing them by hand. Deriving instances is not just more convenient but also safer and encourages deduplication and code reuse.

Currently GHC provides three different strategies for deriving instances: stock, anyclass and newtype. The stock strategy is the original approach to deriving in Haskell and is “magic”: it is hardcoded in the compiler and only works on a predefined set of classes, such as Eq, Show, Typeable, Functor and so on.

The anyclass strategy is just syntactic sugar for writing empty instance declarations and we will not be focusing on it here. The most...

Continue reading →


Free, Finally

Most Haskell programmers have come across the term “free”, often used in conjuction with “monad”, “monoid”, “algebra”. Though I never had a problem understanding these concepts in isolation, it was not entirely clear to me how they related to their definition in category theory.

Given a forgeful functor U : C -> D an object x ∈ D, we define a free C-object on x as an object y ∈ C and a morphism η : x -> U y in D such that for any z ∈ C and f : x -> U z, there exists a unique g : y -> z such that U g ∘ η = f.

free diagram

Normally we will pick our C to be a category of some algebraic structure such as monoids, groups etc, and D to be Set (or as we like to call it in Haskell: Type). Intuitively U is forgetful because it removes struture from a set. For example, consider a forgetful functor from Monoid -> Type. A free monoid on a consists of a monoidal type FreeMonoid a together with a morphism...

Continue reading →


Minimal type-safe static pointers

GHC 7.10 introduced a new language construct called static pointers. The goal is to allow safe and efficient sharing of morally top-level definitions across processes boundaries. This is most commonly used for sending functions (not serializable on their own in Haskell). In this post we will look at how static pointers are currently unsafe (as of GHC 8.4.2), look at a proposed specification to make them safer, and how we can achieve the same guarantees with the current GHC version.

Static pointers are often mixed up with Cloud Haskell and various high-level libraries that make use of them, but in this post we will concentrate on the minimal API provided by GHC, see how to make it safe, and how powerful features can be built on top of it.

The main use of static pointers is sharing functions, but GHC generalizes the concept to work for arbitrary expressions. The basic idea is simple: we...

Continue reading →