Yes, I agree completely, when we stay inside Haskell. However, Clojure is dynamic. Here are two objects that are equal despite having different types:
Consider this case: (= [1] (list 1)) ;=> true (isa? (type [1]) (list 1)) ;=> false In fact, equality in Java (and Clojure) depends on the implementation of equals and hashCode, so, as in the previous example, it is possible that two things are equal while having different type. I know, these are special cases, but a library that wants to be idiomatic has to support even those special cases that are common in a language. So, a bind that operates on a vector might return a list - different types, different monad, but still equal! I am not sure what would be the best solution, I'm just giving a counterexample that illustrates why these things in Clojure are not that straightforward as in Haskell. On Wednesday, July 3, 2013 6:20:08 PM UTC+2, Nils Bertschinger wrote: > > Hi, > > Am Mittwoch, 3. Juli 2013 16:49:43 UTC+2 schrieb Dragan Djuric: >> >> Monads as a Haskell construct is what the previously mentioned laws >> describe. Monads in category theory are defined in a category X as a triple >> (T, n, m) where T is a functor and m and n certan natural transformations >> such that certan diagrams commute. In that sense, I am not sure that even >> Haskell's implementation is perfectly clean. >> > > in category theory, monads are functors with additional constraints. > Haskell's implementation is clean to the extend that Hask, i.e Haskell > types and morphisms between them, form a category (there are some issues > with laziness). > The connection to the categorical definition is most easily seen if you > define monads using "join" instead of ">>=" (bind). You basically need a > functor, i.e. a type constructor with a proper fmap (check the laws here as > well), and two natural transformations mu, eta. As it turns out, > polymorphic functions are natural transformations in Haskell's category, > i.e. they always obey the required laws, no need to check them. Let's call > your functor type t, then mu and eta have the following types: > mu :: a -> t a -- Haskell's return > eta :: t (t a) -> t a -- Haskell's join > > The required laws now state that: > eta (eta mm) = eta (fmap eta mm) > eta (mu m) = eta (fmap mu m) = identity > which just says that if you have something of type t (t (t a)) it does not > matter whether you flatten it from the inside or outside first and if you > have something of type t a, you can put it into another t from the outside > or inside and flatten it to get back the identity. > > Now, conceptually changing the monad does not make much sense. Remember > that a monad is a functor with additional structure, so we are always > working in the same functor! The laws just express that we have a special > functor which obeys additional properties, besides the functorial ones. > > Also generalizing the types of (>>=) to support different monads is > forbidden by the laws. Try to define > myBind :: (Monad m, Monad n) => m a -> (a -> n b) -> n b -- like > (>>=), but changes the monad > and now look at the second law: > > x >>= return = x > or written with explicit types: > ((x :: m a) >>= (return :: a -> m a)) :: m a = x :: m a > > ((x :: m a) `myBind` (return :: a -> n a)) :: n a > but this cannot equal (x :: m a), since it does not even have the same > type! > > Best, > > Nils > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
