Comments on: Parameterized Monads in Haskell

By: Garden Seed

Garden Seed — Mon, 28 May 2012 13:43:05 +0000

The post is written in very a good manner and it entails many useful information for me. I am happy to find your distinguished way of writing the post. Now you make it easy for me to understand and implement the concept.

By: Der Blog (mk II) » Blog Archive » Parameterised monads

Der Blog (mk II) » Blog Archive » Parameterised monads — Sun, 15 Feb 2009 22:43:59 +0000

[...] It seems that a module has already been written to encode parameterised modules and uploaded to Hackage: Control.Monad.Parameterized (package monad-param). It dates from before the current excitement (2007 and it’s at version 0.0.2) so the concept is apparently not new. It does however take a somewhat different approach, one that’s seemingly more general but also more cumbersome. The change in approach is explained in a blog post by its author, Edward Kmett. Here’s what the “parameterized monad” class would look like if translated from the paper: > class PMonad m where > returnP :: a -> m p p a > (>>>=) :: m p1 p2 a -> (a -> m p2 p3 b) -> m p1 p3 b [...]

By: Cora Bass

Cora Bass — Thu, 13 Nov 2008 05:40:50 +0000

2awx0pd6ozbp4lg8

By: Edward Kmett

Edward Kmett — Sat, 14 Jul 2007 02:30:06 +0000

It seems that Oleg’s version mentioned there was the one I linked to above for a form of restricted monad, where the parameter passed to the monad is restricted as to the types it can take, limiting it to being an endofunctor supporting injections from a portion of the category smaller than the whole of the category of all types.

Unfortunately that isn’t so useful for the part of this I was working up next.

What I need (for something else) is a monad that could contain anything, but where I could either vary a type parameter which can be done through a fairly boring MTL-style bit of typeclass hackery, in which case all of the nice examples in the parameterized monad module would require a lot of ‘lift’ style plumbing or where I could change out the monad itself, which was the path I decided to try out.

The main reason I decided to write out the above was because of the fairly interesting (to me anyways) property that by employing the monad laws we get back a notion of type inference for that weakened type for bind.

Er.. that is unless you are referring to somewhere else where Oleg wrote up another form of parameterized monad. Which is quite likely, as I’ve just grown to assume anything worth doing in Haskell or Scheme has already been done by him and is just waiting for someone to come along and read the message on the mailing list.

By: Chung-chieh Shan

Chung-chieh Shan — Fri, 13 Jul 2007 22:07:52 +0000

Oleg represented parameterized monads differently: http://www.haskell.org/pipermail/haskell-prime/2006-February/000498.html The way to think about parameterized monads is that they are like monads except there is mutable state at compile time. In other words, each action in a parameterized monad has a start state and an end state that is checked at compile time: the end state of one action must match the start state of the next action.