Random Hacks: How to make Data.Set a monad

"How to make Data.Set a monad" by Adriaan Moors

Mon, 30 Apr 2007 13:48:09 -0400

Interesting! Scala’s support for subtyping, higher-kinded types (as of 2.5.0, or in a nightly build), and implicit arguments makes it easy to define type classes that abstract over type class contexts (such as Ord a => in the case of Set as an instance of Monad).

A simplified version (without the implicits to fully model type classes) looks like this: (full source)

trait Monad[T <: Bound[T], MyType[x <: Bound[x]], Bound[_]] {
  def map[S <: Bound[S]](f: T => S): MyType[S] 

  def flatMap[S <: RBound[S], RContainer[x <: RBound[x]], RBound[_],  
              Result[x <: RBound[x]] <: Monad[x, RContainer, RBound]]
              (f: T => Result[S]): Result[S] 

  def filter(p: T => Boolean): MyType[T]
}

class Set[T <: Ordered[T]] extends Monad[T, Set, Ordered]

Essentially, this says Monad is a type constructor that takes a type T, a type constructor MyType, and a type constructor Bound. More specifically:

Bound must be of kind * -> *
T must be of kind * and be a subtype of (Bound T)
MyType is of kind * -> * and its first argument (call it x) must be a subtype of (Bound x)

PS: If you’d like more details, let me know (adriaan |at| cs/kuleuven/be)—I’ve been working on adding support for type constructor polymorphism (as we tend to call higher-kinded types etc.) to the Scala compiler over the past couple of months.

"How to make Data.Set a monad" by Miles Gould

Fri, 30 Mar 2007 13:38:07 -0400

Nice one! I ran into the problem of trying to define a monad on a subcategory of the category of types rather than on the whole thing a while back, but couldn’t get anywhere with it – nice to see some solutions!

"How to make Data.Set a monad" by Pepe Iborra

Sat, 17 Mar 2007 10:08:29 -0400

The TH solution is very interesting indeed, since one would probably want to have code using your restricted monad as well as vanilla monads in the same module.

In that case, rebinding the do notation via -fnoimplicit-prelude is not an option. Otherwise, you need to keep code that uses a restricted monad in a separate module, which would get annoying very quickly.

"How to make Data.Set a monad" by Eric

Fri, 16 Mar 2007 08:09:36 -0400

alpheccar: Note that you don’t need Template Haskell if you use -fno-implicit-prelude, as Brandon points out.

Still, the Template Haskell solution is definitely interesting in its own right: There are some nice features there, which could be useful for other things.

pepe: Oh, that’s cool. That might be the right way to get something like this into standard Haskell.

"How to make Data.Set a monad" by pepe Iborra

Fri, 16 Mar 2007 04:32:58 -0400

Yeah, very cool stuff! It might be that Associated Types could provide a cleaner solution (see here), but this one is good enough for me.

"How to make Data.Set a monad" by alpheccar

Fri, 16 Mar 2007 02:33:07 -0400

I recently used the GADT method to implement a restricted monad on my blog.

But, I prefer the solution with template Haskell. Good idea !

"How to make Data.Set a monad" by Eric

Fri, 16 Mar 2007 01:29:05 -0400

Brandon: Thanks! That’s really good to know.

sigfpe: The Template Haskell bits were actually pretty interesting. I’ve been meaning to look at Haskell code-generation for a while, and I’m pleased to discover that things mostly work.

There are definitely some missing pieces in the API, though—not all of Haskell’s grammar is actually available, and splicing is very limited. So Template Haskell is less powerful than Lisp macros (and it lacks the runtime code-generation support of MetaOCaml). But it’s still powerful enough to allow for some interesting applications.

"How to make Data.Set a monad" by sigfpe

Fri, 16 Mar 2007 00:46:02 -0400

Nice! That looks like it probably needed a lot of persistence to get working.

There’s also this which I haven’t tried yet.

"How to make Data.Set a monad" by Brandon S Allbery KF8NH

Thu, 15 Mar 2007 23:58:49 -0400

If you use -fno-implicit-prelude, GHC will use whatever (>>=) is in scope instead of pulling in (Prelude.>>=) behind your back; see section 7.3.5 of the User’s Guide.

How to make Data.Set a monad

Eric Kidd — Thu, 15 Mar 2007 22:29:00 -0400

…and how to fake Lisp macros with Template Haskell

(I wrote this article in response to a comment by sigfpe. You may find it pretty dry reading, unless you want to build domain-specific languages in Haskell. Proceed at your own risk.)

Haskell’s built-in Monad type has some serious limitations. We can fix those limitations using a number of advanced Haskell techniques, including Template Haskell, Haskell’s closest equivalent to Lisp macros.

We can illustrate the limitations of Monad with an example from math. In set theory, we can define a set by specifying how to compute each element:

{ xy : x ∈ {1,2,4}, y ∈ {1,2,4} }

We can read this as, “the set of all xy, where x is one of {1,2,4}, and y is one of {1,2,4}.” To calculate the answer, we first multiply together all the possible combinations:

1×1=1, 1×2=2, 1×4=4, 2×1=2, 2×2=4, 2×4=8, 4×1=4, 4×2=8, 4×4=16

We then collect up the answers, and—because we’re working with sets–we throw away the duplicates:

{1,2,4,8,16}

Can we do the same thing in Haskell? Well, using Haskell’s list monad, we can write:

listExample = do
  x <- [1,2,4]
  y <- [1,2,4]
  return (x*y)

But when we run this, Haskell gives us lots of duplicate values:

> listExample
[1,2,4,2,4,8,4,8,16]

Our problem: We’re using lists (which can contain duplicate values) to represent sets (which can’t). Can we fix this by switching to Haskell’s Data.Set?

import qualified Data.Set as S

-- This doesn't work.
setExample = do
  x <- S.fromList [1,2,4]
  y <- S.fromList [1,2,4]
  return (x*y)

Unfortunately, this code fails spectacularly. A Haskell monad is required to work for any types a and b:

class Monad m where
  return :: a -> m a
  fail :: String -> m a
  (>>=) :: m a -> (a -> m b) -> m b

But Data.Set only works for some types. Specifically, it requires that values of type a can be ordered:

data (Ord a) => Set a = ...

As it turns out, we can make Data.Set into a monad. But be warned: The solution involves some pretty ugly Haskell abuse.