I'm beginning to think that all the people who have ever understood monads have written an article trying to explain them.
And that somehow in understanding monads, the lose the capability of explaining them.
Monads explained by Eric Lippert
31–40 of 58 posts
Re: Monads explained by Eric Lippert
#32I'm beginning to think that all the people who have ever understood monads have written an article trying to explain them.
Only three kinds of people have ever understood Monads - some of them died, others went mad trying to formulate explanations and the rest have forgotten all about them.
Re: Monads explained by Eric Lippert
#33Monads should be a familiar concept for the seasoned C# programmer. LINQ's 'from in' syntax and the haskell monad 'do' syntax are almost the same! Heck, the type signature of SelectMany and (>>=) are even the same! (>>=) :: m a -> (a -> m b) -> m b and public static IEnumerable SelectMany ( this IEnumerable source, Func > selector ) m = IEnumerable b = TResult a = TSource => m SelectMany (this m source, Func > select…
Likewise, Scala's "for" loop compiles to calls to map and flatMap, which are the same as Select and SelectMany, which represent the list monad. You can use map, flatMap, and for notation in lieu of a more generally named do syntax.
Re: Monads explained by Eric Lippert
#34@DigitalJack's comment [http://news.ycombinator.com/item?id=5325542] reminded me of another talk on monads viewed by me recently, by none other than dear ol' Dougie!
http://www.yuiblog.com/blog/2012/12/13/yuiconf-2012-talk-dou...
Re: Monads explained by Eric Lippert
#35Note that this is a series of posts. The first post that is being linked to doesn't have much IMO. http://ericlippert.com/2013/02/21/monads-part-one/ http://ericlippert.com/2013/02/25/monads-part-two/ http://ericlippert.com/2013/02/28/monads-part-three/ I wasn't clear for me but in the last post he mentioned that there would be more posts to come.
He sure takes his time..
Episode 4: Conclusion: But we are so close! Next time on FAIC we'll make a small but vital modification to the signature pattern ApplyFunction to arrive at the actual second requirement of the monad pattern.
Re: Monads explained by Eric Lippert
#36Monads are complicated because the word "monad" bears too much weight in any discussion about them. 1) There is a category theoretical concept of a monad. This is largely irrelevant in a practical explanation of monads since Monads are usually talked about in terms of another category theoretical concept called the Kleisli Category or Kleisli Triple. However, if someone starts talking about "monad laws", they're prob…
Minor nitpicks: "Monadic types" and "Monadic values" would be better for 4 and 5, because "Monad types" are the type constructors (which are also sometimes named types). And "monad values" is not a term I've ever heard used. Also, values have-type, they're not instance-of. So it would be slightly more accurate to say monadic values are values of a monadic type, whose type constructor is an instance of the Monad type-…
I'm sure I've made some terminology decisions that are questionable, but in light of someone writing the community approved guide to talking about monads, I'll try to explain what I was trying to get across.
First, I was trying to emphasize that a type constructor is not strictly a type in the sense of a value having a type. While we commonly speak about to the parameterized types without their type arguments, they aren't really "types" in the type theory sense while there are still type arguments to be supplied. That is, "Maybe"'s kind is * -> * while Maybe a's kind is * even though a is a generic type.
When referring to something as a "monadic value" I was just trying to emphasize that the monad that contains a value is itself a value in the Haskell runtime system and that such a "monadic value" is separate from the value contained there within.
Finally, maybe this is a bad habit of mine, but I've always referred to values as instances since they inhabit types.
I disagree that the namespacing is only ever an issue for a complete beginner. The visual separation between a type expression and a value expression in Haskell can be pretty thin. It's not just about whether they are unambiguous but how much attention you have to pay to while you're skimming code. Honestly, I don't think there's much that can be done about it, but it's just the cherry on top for beginner and intermediate users. Especially ones who aren't using Haskell regularly.
Re: Monads explained by Eric Lippert
#37Note that this is a series of posts. The first post that is being linked to doesn't have much IMO. http://ericlippert.com/2013/02/21/monads-part-one/ http://ericlippert.com/2013/02/25/monads-part-two/ http://ericlippert.com/2013/02/28/monads-part-three/ I wasn't clear for me but in the last post he mentioned that there would be more posts to come.
He sure takes his time.. Episode 4: Conclusion: But we are so close! Next time on FAIC we'll make a small but vital modification to the signature pattern ApplyFunction to arrive at the actual second requirement of the monad pattern.
Eric is attempting to explain it to a wide class of C# developer -- most of whom are pretty unfamiliar with lambdas and higher-order functions, much less eclectic type polymorphism and computation.
Re: Monads explained by Eric Lippert
#38I'm beginning to think that all the people who have ever understood monads have written an article trying to explain them.
I understand monads and use them everyday, but I've never written an article about them. I did once try to explain to someone what a monad is... that could be the reason I've never tried.
Re: Monads explained by Eric Lippert
#39I'm beginning to think that all the people who have ever understood monads have written an article trying to explain them.
I understand monads and use them everyday, but I've never written an article about them. I did once try to explain to someone what a monad is... that could be the reason I've never tried.
You should write an article!
Re: Monads explained by Eric Lippert
#40I'm beginning to think that all the people who have ever understood monads have written an article trying to explain them.
I understand monads and use them everyday, but I've never written an article about them. I did once try to explain to someone what a monad is... that could be the reason I've never tried.
I understand monads and use them everyday,
Same thing here and I am not writing a tutorial, because good tutorials already exist. For example:
http://blog.sigfpe.com/2006/08/you-could-have-invented-monad... http://www.manning.com/bjarnason/
In fact, the latter book lets you write your own functors and monads without even telling you, and then shows you that you actually already understand these concepts.