Comments for Lane's Blog http://blog.downstairspeople.org A blog of fleshlings and robots. Wed, 25 Jan 2012 12:18:41 +0000 hourly 1 http://wordpress.com/ Comment on The One Function per Typeclass Rule by Edward Z. Yang http://blog.downstairspeople.org/2011/03/16/type-coercion-in-haskell/#comment-129 Wed, 25 Jan 2012 12:18:41 +0000 http://clanehin.wordpress.com/?p=293#comment-129 Another thing you have to be quite careful about is the coherency of the laws of a type class. For example, I’ve recently been arguing that it doesn’t make too much sense to split up an asynchronous exception type class into three components, because the semantics of exceptions don’t really make sense unless you have all the components.

With constraint kinds, one-function-per-class should become more pleasant to work with, however.

]]> Comment on A Brutal Introduction to Arrows by Per Persson http://blog.downstairspeople.org/2010/06/14/a-brutal-introduction-to-arrows/#comment-106 Sun, 11 Sep 2011 08:40:00 +0000 http://blog.downstairspeople.org/?p=141#comment-106 My reaction to this example was: So what, this could certainly be done with monads. When I tried to do it, however, I met problems with implementing >>= for the wrapped IO monad. So I suppose that it can’t be done with monads.

]]> Comment on The One Function per Typeclass Rule by Dan Doel http://blog.downstairspeople.org/2011/03/16/type-coercion-in-haskell/#comment-84 Wed, 16 Mar 2011 18:52:14 +0000 http://clanehin.wordpress.com/?p=293#comment-84 There’s at least one big exception to this being a good rule: classes with somehow mutually definable methods. For instance, Ord

class Ord a where
compare :: a -> a -> Ordering
( a -> Bool
...

It actually has a lot of methods, and sensibly so, because any one of several works as the default (although, the defaulting facilities could be buffed as well: let me specify all possible defaults, with implementations in terms of each, instead of working out an implicit graph with one or two possible nodes like now).

Another I want is:

class ... => Monad m where
(>>=) :: m a -> (a -> m b) -> m b
join :: m (m a) -> m a

I should be able to pick which I want to define. Or both if I want. And allowing me to override some more specific combinators isn’t a bad idea either, like the new Functor:

class Functor f where
fmap :: (a -> b) -> f a -> f b
( f b -> f a

Applicative and Monad are likely to have similar possible, “this could be significantly more efficient for some implementations,” methods. People seem averse to this sort of thing (and often suggest RULEs instead, which are unportable), but I don’t really see the problem with indulging a bit (you can obviously go overboard).

As an additional aside: I’m not sure we can blame the ‘various kinds of failure’ mess on multiple methods specifically. It’s a combination of factors.

1. fail exists for dubious reasons that don’t have to do with a separate class. Failure was specifically intended to be possible for every Monad in H98.
2. Alternative exists separately from MonadPlus because the latter predates Applicative, but there’s no reason to require all MonadPlusses to be a Monad. So it’s a hierarchical (and legacy code) issue.
3. Monoid exists apart from the others (at least) because you cannot write a constraint like (forall a. Monoid (m a)). So it’s a type system issue.

Anyhow, I don’t see anything wrong with one-function-per-class as a basic guideline, but I wouldn’t want it to be enforced by the language for instance (like it used to be in Clean).

]]>