Re: Why use monads
Don't really understand what point you're making. The way I see it, monads are incredibly useful for combining functions that all have the same signature. When you realize that that's the domain you're working in, you can use a monad and raise the level of abstraction that you're working at. In this area, the task seems to be educating programmers about how to use monads effectively. Lot of work yet to do, yet the theoretical foundation seems to be solid. Composing monads is a totally different subject with a lot of theoretical work yet to be done. Presently, monad transformers seem to be the way forward, but that's open to debate as you've pointed out. Vagif Verdi wrote: > On Dec 22, 2:10 pm, jim wrote: > > Chouser, > > > > You're right that maybe-comp is simpler. Once you realize that the > > functions you want to compose are monadic functions under the maybe-m > > monad, you get that composition for 'free', with no further mental > > effort. > > Except different types of monads do not compose, so you have to create > another artificial structure called monad transformers. And these new > structures introduce so much new artificial complexity that any > possible simplification becomes a moot point. > > This fact is realized even in haskell community: > http://lambda-the-ultimate.org/node/2749#comment-41078 > > I'd say that monads add way too much complexity in most cases. > Especially in impure languages where you can do many things much > simpler than involving monads. -- 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
Re: Why use monads
On Mon, Dec 28, 2009 at 12:44:31PM +0100, Konrad Hinsen wrote: >> This fact is realized even in haskell community: >> http://lambda-the-ultimate.org/node/2749#comment-41078 > >That article is about monad transformers, not monads themselves. BTW, >monad transformers are simpler in Clojure than they are in Haskell >(they are ordinary functions), so some arguments in that thread don't >apply to the same degree. Well, they still end up mostly as just functions in Haskell, with lots of extra wrapping and unwrapping to get the type system to work. The advantage in Haskell, is that 'lift' and friends (liftIO) figure out at compile time how many invocations are needed to get to the right monad. My biggest complaint about the monad transformers was that they make the program design fragile. Having to make small changes to what monads were used tended to have a pervasive effect on the rest of the code. Much of this had to do with type declarations, so this might not be as much of an issue with Clojure. David -- 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
Re: Why use monads
On 27.12.2009, at 23:03, Vagif Verdi wrote: > Except different types of monads do not compose, so you have to create > another artificial structure called monad transformers. And these new > structures introduce so much new artificial complexity that any > possible simplification becomes a moot point. Please don't confuse the composition of computational steps in a monad with the composition of several monadic effects into a single combined monad. The first is quite well understood and I have yet to see anyone who has used monads in real life claim that they are not useful. The second aspect is more difficult and less well understood. The current most popular approach, monad transformers, may turn out to be insufficient or too complicated, and it may or may not be replaced by something else. Time will tell. The important point is that that utility of monads does not depend on monad transformers. > This fact is realized even in haskell community: > http://lambda-the-ultimate.org/node/2749#comment-41078 That article is about monad transformers, not monads themselves. BTW, monad transformers are simpler in Clojure than they are in Haskell (they are ordinary functions), so some arguments in that thread don't apply to the same degree. Konrad. -- 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
Re: Why use monads
On Dec 22, 2:10 pm, jim wrote: > Chouser, > > You're right that maybe-comp is simpler. Once you realize that the > functions you want to compose are monadic functions under the maybe-m > monad, you get that composition for 'free', with no further mental > effort. Except different types of monads do not compose, so you have to create another artificial structure called monad transformers. And these new structures introduce so much new artificial complexity that any possible simplification becomes a moot point. This fact is realized even in haskell community: http://lambda-the-ultimate.org/node/2749#comment-41078 I'd say that monads add way too much complexity in most cases. Especially in impure languages where you can do many things much simpler than involving monads. -- 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
Re: Why use monads
Not on the topic, but quite important - that yellow column on the left is a usability killer, it makes text hard to read. I had to manually change it in Firebug just to read the article. -- 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
Re: Why use monads
On 22.12.2009, at 22:14, Chouser wrote: > It's interesting to me that the definition of maybe-comp above is > arguably simpler that the definition of maybe-m, even without > counting the machinery of 'defmonad'. Presumably this is a hint > to how much more powerful maybe-m is than maybe-comp, and simply > shows I don't yet understand the power of monads. If the only monad you are ever going to use is maybe-m, then indeed you are better off with your specialized maybe-comp function. But you can make the same point about any abstraction; they never pay off for a single application. What you gain with monads compared to maybe-comp and similar special cases is generality: you can apply the monad approach to function composition to many different situations and don't have to start from scratch each time. Konrad. -- 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
Re: Why use monads
I've expanded the tutorial a little. You can skip to "Another example" for the new stuff. I go through the same exercise using the probability monad. http://intensivesystems.net/tutorials/why_monads.html There are some corresponding additions to the sample code as well. Jim On Dec 23, 2:18 pm, Sean Devlin wrote: > +1 ataggart, Chouser > > On Dec 23, 3:02 pm, ataggart wrote: > > > I'd appreciate any added detail, since I had a similar reaction to > > Chouser, thus wasn't really grokking the monad (wikipedia's > > description is no more helpful). > > > On Dec 22, 2:10 pm, jim wrote: > > > > Chouser, > > > > You're right that maybe-comp is simpler. Once you realize that the > > > functions you want to compose are monadic functions under the maybe-m > > > monad, you get that composition for 'free', with no further mental > > > effort. With such a simple example, it's hard to see the benefit, but > > > with more complicated monads the difference between the monad > > > composition and ad-hoc style becomes greater. Where the ad-hoc version > > > would have to be debugged, the monad version would already be proven > > > to be correct. > > > > Beyond that, there are other things that you get 'for free' by using > > > the monad functions. Don't have time to enumerate them now but might > > > later. > > > > Jim > > > > On Dec 22, 3:14 pm, Chouser wrote: > > > > > It's interesting to me that the definition of maybe-comp above is > > > > arguably simpler that the definition of maybe-m, even without > > > > counting the machinery of 'defmonad'. Presumably this is a hint > > > > to how much more powerful maybe-m is than maybe-comp, and simply > > > > shows I don't yet understand the power of monads. > > > > > --Chouser > > > > -- > > > > -- I funded Clojure 2010, did you? http://clojure.org/funding -- 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
Re: Why use monads
I'll see what I can do. On Dec 23, 2:18 pm, Sean Devlin wrote: > +1 ataggart, Chouser > -- 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
Re: Why use monads
+1 ataggart, Chouser On Dec 23, 3:02 pm, ataggart wrote: > I'd appreciate any added detail, since I had a similar reaction to > Chouser, thus wasn't really grokking the monad (wikipedia's > description is no more helpful). > > On Dec 22, 2:10 pm, jim wrote: > > > > > Chouser, > > > You're right that maybe-comp is simpler. Once you realize that the > > functions you want to compose are monadic functions under the maybe-m > > monad, you get that composition for 'free', with no further mental > > effort. With such a simple example, it's hard to see the benefit, but > > with more complicated monads the difference between the monad > > composition and ad-hoc style becomes greater. Where the ad-hoc version > > would have to be debugged, the monad version would already be proven > > to be correct. > > > Beyond that, there are other things that you get 'for free' by using > > the monad functions. Don't have time to enumerate them now but might > > later. > > > Jim > > > On Dec 22, 3:14 pm, Chouser wrote: > > > > It's interesting to me that the definition of maybe-comp above is > > > arguably simpler that the definition of maybe-m, even without > > > counting the machinery of 'defmonad'. Presumably this is a hint > > > to how much more powerful maybe-m is than maybe-comp, and simply > > > shows I don't yet understand the power of monads. > > > > --Chouser > > > -- > > > -- I funded Clojure 2010, did you? http://clojure.org/funding -- 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
Re: Why use monads
I'd appreciate any added detail, since I had a similar reaction to Chouser, thus wasn't really grokking the monad (wikipedia's description is no more helpful). On Dec 22, 2:10 pm, jim wrote: > Chouser, > > You're right that maybe-comp is simpler. Once you realize that the > functions you want to compose are monadic functions under the maybe-m > monad, you get that composition for 'free', with no further mental > effort. With such a simple example, it's hard to see the benefit, but > with more complicated monads the difference between the monad > composition and ad-hoc style becomes greater. Where the ad-hoc version > would have to be debugged, the monad version would already be proven > to be correct. > > Beyond that, there are other things that you get 'for free' by using > the monad functions. Don't have time to enumerate them now but might > later. > > Jim > > On Dec 22, 3:14 pm, Chouser wrote: > > > > > > > It's interesting to me that the definition of maybe-comp above is > > arguably simpler that the definition of maybe-m, even without > > counting the machinery of 'defmonad'. Presumably this is a hint > > to how much more powerful maybe-m is than maybe-comp, and simply > > shows I don't yet understand the power of monads. > > > --Chouser > > -- > > -- I funded Clojure 2010, did you? http://clojure.org/funding -- 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
Re: Why use monads
Chouser, You're right that maybe-comp is simpler. Once you realize that the functions you want to compose are monadic functions under the maybe-m monad, you get that composition for 'free', with no further mental effort. With such a simple example, it's hard to see the benefit, but with more complicated monads the difference between the monad composition and ad-hoc style becomes greater. Where the ad-hoc version would have to be debugged, the monad version would already be proven to be correct. Beyond that, there are other things that you get 'for free' by using the monad functions. Don't have time to enumerate them now but might later. Jim On Dec 22, 3:14 pm, Chouser wrote: > > It's interesting to me that the definition of maybe-comp above is > arguably simpler that the definition of maybe-m, even without > counting the machinery of 'defmonad'. Presumably this is a hint > to how much more powerful maybe-m is than maybe-comp, and simply > shows I don't yet understand the power of monads. > > --Chouser > -- > -- I funded Clojure 2010, did you? http://clojure.org/funding -- 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
Re: Why use monads
On Mon, Dec 21, 2009 at 7:18 PM, jim wrote: > Just posted a short piece on why monads are useful. This was prompted > by some conversations last week with some folks. Comments, questions > and criticisms welcome. > > http://intensivesystems.net/tutorials/why_monads.html Thanks for writing that up. I keep reading approachable tidbits about monads like this, without really digging into learning all there is to know about monads. It's hardly fair of me to comment on this at all before I do that deeper digging, but for what it's worth here's a non-monadic solution to the particular problem presented. It's just a high-level function that defines a comp-like fn with the desired behavior: (defn maybe-comp [& fns] (fn [x] (reduce #(when %1 (%2 %1)) x (reverse fns Use it like this: (def all (maybe-comp dec-m double-m inc-m)) It's interesting to me that the definition of maybe-comp above is arguably simpler that the definition of maybe-m, even without counting the machinery of 'defmonad'. Presumably this is a hint to how much more powerful maybe-m is than maybe-comp, and simply shows I don't yet understand the power of monads. --Chouser -- -- I funded Clojure 2010, did you? http://clojure.org/funding -- 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
