Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why monads have not taken the Common Lisp world by storm (2008)

marijnhaverbeke.nl

Post reply on HN
Print view View original

41–49 of 49 posts

Re: Why monads have not taken the Common Lisp world by storm (2008)

#41

Post by yohanatan »

fusiongyro wrote: post #21
octo_t wrote: post #7

Earlier quoted context omitted.

Scala has plenty of monads and they work fine.

Yes, but doesn't it also have the three requirements mentioned by the article: ML-style function foo, something akin to type classes, and polymorphic return types?

In Scala, currying is not all-pervasive. You have to be explicit about it (and it's a definite pain point).

Re: Why monads have not taken the Common Lisp world by storm (2008)

#42

Post by danidiaz »

tel wrote: post #36
jeremyjh wrote: post #27

Earlier quoted context omitted.

>Yes, Haskell makes you "recreate" the RWST monad stack that imitates impure languages This is really a point that seems to get lost in most of learning materials on the web. LYAH doesn't even acknowledge transformers. I am pretty new to Haskell but it seems to me that transformer stack decisions are a pretty significant design decision for your application. What has happened to me is almost all the code in my applic…

That's definitely a stage of a Haskell program design. The stack helps to separate out layers of effects, but it can be easy to fix that stack concretely at an early stage and then feel the weight of it later on with overly specialized functions. The solution is usually to use the mtl-style transformer classes which let you write generalized functions which depend upon capabilities of the transformer stack instead of…

For maximum modularity, you can combine this with functions like "zoom" and "magnify" of module Control.Lens.Zoom. They let you convert stateful operations that work on a fragment of the global state/environment into operations that work with the whole state/environment (provided that you have the appropriate lenses.) Very useful in complex monad stacks.

Re: Why monads have not taken the Common Lisp world by storm (2008)

#43

Post by nandemo »

tel wrote: post #36
jeremyjh wrote: post #27

Earlier quoted context omitted.

>Yes, Haskell makes you "recreate" the RWST monad stack that imitates impure languages This is really a point that seems to get lost in most of learning materials on the web. LYAH doesn't even acknowledge transformers. I am pretty new to Haskell but it seems to me that transformer stack decisions are a pretty significant design decision for your application. What has happened to me is almost all the code in my applic…

That's definitely a stage of a Haskell program design. The stack helps to separate out layers of effects, but it can be easy to fix that stack concretely at an early stage and then feel the weight of it later on with overly specialized functions. The solution is usually to use the mtl-style transformer classes which let you write generalized functions which depend upon capabilities of the transformer stack instead of…

s/Prolog/Monoid/

Re: Why monads have not taken the Common Lisp world by storm (2008)

#44

Post by tel »

nandemo wrote: post #43
tel wrote: post #36

Earlier quoted context omitted.

That's definitely a stage of a Haskell program design. The stack helps to separate out layers of effects, but it can be easy to fix that stack concretely at an early stage and then feel the weight of it later on with overly specialized functions. The solution is usually to use the mtl-style transformer classes which let you write generalized functions which depend upon capabilities of the transformer stack instead of…

s/Prolog/Monoid/

I meant the Prolog-like inference where MonadWriter w m implies Monoid w.

Re: Why monads have not taken the Common Lisp world by storm (2008)

#45

Post by samth »

moomin wrote: post #39
marijn wrote: post #9

Earlier quoted context omitted.

Scala has a much more powerful type system than Clojure

100% true, but not as powerful as Haskell's. Not sure you can usefully have inheritance and return type overloading.

The Scala and Haskell type systems are incomparable, and the typeclass aspects that are most relevant to monad usability are doable with implicits.

Re: Why monads have not taken the Common Lisp world by storm (2008)

#46

Post by chongli »

tonetheman wrote: post #20
gernotk wrote: post #13

Earlier quoted context omitted.

This talk by Douglas Crockford is quite informative: http://www.youtube.com/watch?v=dkZFtimgAcM

Cool thanks!

I actually prefer Brian Beckman's explanation:

http://www.youtube.com/watch?v=ZhuHCtR3xq8

Re: Why monads have not taken the Common Lisp world by storm (2008)

#47

Post by gtani »

tonetheman wrote: post #10

I came here to make a joke about the real reason why was that no one understands them... but apparently everyone here does. Off to google monads for idiots...

I think the proper presentation of this material is as how Learn you a haskell[1] does it: functors, applicatives, monoids ... then monads but I don't think i've seen this done for other languages. Each of those structures should be learned as a set of properties, rather than something concrete (container, wrapper, sequencer, programmable semicolon) and then you see how important the applicative vs monadic style decision is for library design in haskell

[1]http://learnyouahaskell.com/functors-applicative-functors-an...

Re: Why monads have not taken the Common Lisp world by storm (2008)

#49

Post by tel »

nandemo wrote: post #48
tel wrote: post #44

Earlier quoted context omitted.

I meant the Prolog-like inference where MonadWriter w m implies Monoid w.

I see. That was a bit obscure, though.

Ah, sorry, I was accidentally writing in the context of another comment I wrote in this thread where I talked about the typeclass resolution machinery. Without that context, it is pretty out of place.
Post reply on HN