Hi Ben and everyone who participated in the discussion. Most of the issues we have been discussed (most notably mdo and agnostic return) have been implemented in the newly released version 0.3.0. No macrology was necessary for agnostic return :) Please try the new version and post your feedback.
On Wednesday, July 3, 2013 9:31:58 PM UTC+2, Ben wrote: > > On Wed, Jul 3, 2013 at 7:49 AM, Dragan Djuric <drag...@gmail.com<javascript:> > > 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.
