On Wed, Jul 3, 2013 at 7:49 AM, Dragan Djuric <draga...@gmail.com> wrote:

> 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.
>
> There's a lot of nitpicking to be done, but, that's not the point, and we
> are digressing a bit. The point is that in Fluokitten, you are expected to
> work within the certain monad as you agree, and since there is no type
> checking on the value that a function returns, it is the responsibility of
> the developer to make sure that it makes sense as in Clojure generally. It
> is fairly easy to do by passing a parameter to f that pure can use, if f
> implementation needs to be agnostic to the actual monad that it will be
> called from.
>
> There are other approaches, so the programmer can make a choice that is
> the best fit for the problem at hand.
>
> Even in the example that you gave from your library, what stops the
> programmer to shoot himself in the foot by doing basically the same thing
> that we are talking about here:
>
> (defn f [g] (comp atom g g))
>
> (require '[monads.maybe :as m])
>
> (def mc (>>= (return 3) (f inc)))
>
> (run-monad m/m mc)
>
> What is the result if f is broken (in the context of the monad m/m in this
> case)? I didn't try it, so I may be wrong, but I doubt that the Clojure
> compiler complains about that one.
>

Of course the compiler doesn't complain, how could it? I'm not asking you
to have the clojure compiler complain. I'm attempting to point out that
your library makes it impossible to write generic functions involving
monads. That is, for fluokitten, you *have* to write f as something like
(comp atom g g) or (comp vector g g) or (comp just g g) or whatever. You
don't have the option of writing (comp return g g) and having that work
right when the function is run in *multiple* monads. Which is a major
expressivity drawback, in my mind. This is basically the same thing as
comes up with Armando Blancas' morph library, which is, like yours, based
on protocols.

The expressivity point is the key, not the nonexistent haskell-in-clojure
typechecker. That's why I asked the question I asked in my first email:
whether it's possible to write this function (which I've desugared):

(defn tst-reader [f] (>>= ask (fn [env] (>>= (lift (f env)) (fn [_] (>>=
(return (println "here I am")) (fn [_] (return v))))))))

which can operate in an instance of the reader monad transformer
parametrized by an *arbitrary* inner monad---so that you don't know in
advance what the "return" or ">>=" should be (and you don't know in advance
what the "lift" should be, since more than one interpretation of the reader
monad is possible---all that's required here is that the monad support an
"ask" operation). I suppose you could thread specimen special return, bind,
ask, and lift functions through (and if you used fancy macrology to do
that, you'd have the core.monads approach), but that's really quite
cumbersome.

IMO, the ability to write code like that is a large part of what makes
monadic abstraction powerful and interesting.

-- 
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks, which
may be sweet, aromatic, fermented or spirit-based. ... Family and social
life also offer numerous other occasions to consume drinks for pleasure."
[Larousse, "Drink" entry]

-- 
-- 
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.


Reply via email to