The specific bind implementations always get the instance of the Monad protocol the bind was called with (since it is a part of an implementation of the Monad protocol), so you use that instance as a first argument to pure.
Of course, if you call bind with a function that does not make sense in a context, you'll get a runtime exception, like in the rest of Clojure. Clojure is not strongly typed, so it puts some expectations on the programmer. I am not trying to fix Clojure. Thank you for some very thoughtful comments. If you are interested, we can try to write a bit more detailed comparisons of the approaches in both libraries. On Wednesday, July 3, 2013 2:21:29 AM UTC+2, Ben wrote: > > On Tue, Jul 2, 2013 at 5:06 PM, Ben Wolfson <wol...@gmail.com<javascript:> > > wrote: > >> On Tue, Jul 2, 2013 at 4:33 PM, Dragan Djuric <drag...@gmail.com<javascript:> >> > wrote: >> >> >>> Regarding monadic laws, which one exactly demands that you cannot change >>> the monad (not counting the fact that haskell's implementation does it that >>> way)? Here are the laws, in Haskell: >>> >>> return a >>= k = k a >>> m >>= return = m >>> m >>= (\x -> k x >>= h) = (m >>= k) >>= h >>> >>> It seems to me the laws are still satisfied if you keep changing monads >>> in each bind (if compiler is not restricting it, as is the case with >>> Haskell but not with Clojure). >>> >> >> I suppose that may be right: you're supposed to verify that the laws >> obtain for a putative monad; they don't come for free just by calling >> something a monad. Allowing >>= to have the type m a -> (a -> n b) -> n b >> just means that you can't verify that yours obeys the laws. If you get to >> choose the type of "return", even the second one is up for grabs! It does >> seem somewhat odd to me to advertise the package as being familiar to >> Haskellers and to employ category-theoretic concepts and then to be so >> blasé about the definition of a monad. (I wonder if you can get away with >> this changing of type at all if you define bind in terms of fmap and join). >> > > > How are you even supposed to implement bind, in fact? (Never mind > reasoning about what's going on in your program if you can't be certain > that the code won't switch out the monad you think you're working in, when > it does matter to you that you're in a specific one.) Generally for some > specific monad you need to do something specific with the return of f. For > instance, your seq-bind is implemented in terms of mapcat---meaning that > the f that's the second argument of mapcat had better return a seqable. > This doesn't work: (mapcat (comp atom inc) '(1 2 3)). > > -- > 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.
