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

Functor, Applicative, and Monad

typeslogicscats.gitlab.io

Post reply on HN
Print view View original

31–40 of 125 posts

Re: Functor, Applicative, and Monad

#31

Post by kovek »

TheAsprngHacker wrote: post #9
mesarvagya wrote: post #2

Even better http://adit.io/posts/2013-04-17-functors,_applicatives,_and_...

I am the author of this submission. I have strong opinions about functor and monad tutorials, and here are my thoughts: Back when I didn't understand what a monad was, I would read a bunch of tutorials and get confused by the analogies and examples. For example, I would get confused by comparisons to "boxes," or I would think that Maybe was the definition of a monad, or that IO was the definition of a monad. The info…

Hi! Reading your tutorial I wanted to leave a quick comment on HN and was worried you wouldn't see it. Nice to see you're present!

Thanks, I liked reading it a lot. It's a good refresher, since I never use haskell but have read about this a couple of times.

The tutorial appears great on mobile, so I was able to refresh my memory very quickly. However, the code boxes had a very small font. I think this could me easily fixed with fome html-fu on the meta tag or the sizing of the box/font.

I also think that it would be great it you could explain at the end what is a counterexample input for the small haskell program. For example, if the user inputs a file that doesn't exist, then the readFile returns Nothing, then putStrLn returns Nothing. There's a sentence in the conclusion that explains that monads are nice to use but not why. I understand that it deals with values inside contexes, but in practice how does it affect development?

Re: Functor, Applicative, and Monad

#32

Post by kccqzy »

mavelikara wrote: post #11
hardwaregeek wrote: post #6

An important realization that I had was that monads/functors/applicatives aren't patterns in the sense of design patterns. You don't solve a singular problem with a monad. With something like a strategy pattern you have a concrete problem: how do I select different potential algorithms? Monads don't have a specific problem that they solve. Any attempt to motivate monads in such a manner falls flat because the problem…

> And therefore, it's perfectly acceptable to say "I know how monads work with Maybe and List, but not Reader" Because fundamentally, how a Reader implements bind is in no way related to how Maybe or List implement bind. If this is indeed true, what is the point of learning these "patterns"? From a mechanical understanding of the signature of bind and unit, you'd arrive at more sophisticated signatures, say filterM,…

Your example, filterM has the type

    filterM :: Applicative m => (a -> m Bool) -> [a] -> m [a]
from this I can tell you conclusively what it does: it takes a monadic function that returns a Bool after performing some "action" as well as a list of values; it then performs this action on each element and look at whether the result is True or False; when True, keep it otherwise discard it.

Now this is already a lot of information on what filterM does. But to use it in an action piece of code, you need to supply your own understanding of what the "action" is in this context. It does not matter whether or not you understand the implementation details of the specific Monad instance. You just need to understand its behavior: with the Reader monad, you know the action in question is just reading a piece of value from a "hidden" environment, so your filtering function has access to this environment when it determines whether or not to keep or retain an element; with the State monad, you know the action in question can possibly modify this environment as well; with the Maybe monad, you know the filtering action can say I don't know and that would result in the entire result to be Nothing as well.

Your argument of functions like filterM being a leaky abstraction is akin to saying, a Java interface is a leaky abstraction because you can't instantiate an interface (you need a class) so you need to understand both the interface as well as the class being used that implements the interface. Instead, think about it, it's just how the nature of combining orthogonal (de-coupled) things requires you to have an understanding of both of the pieces you are combining.

Re: Functor, Applicative, and Monad

#33

Post by hope-striker »

TurboHaskal wrote: post #26
wh0knows wrote: post #17

I don't think this article is very useful. It doesn't adequately provide an introduction to OCaml code (or adequately explain what a given code snipped is doing) and yet frequently defers to just code to explain a concept. It's an unrealistic expectation to expect an unfamiliar reader to simultaneously infer what a particular code snippet is doing then also go a level deeper and understand the concept that is trying…

You claim that OCaml programmers are already versed in category theory but that’s not correct. The first exposure usually comes with concurrency libraries such as Lwt which isn’t very old nor in the standard library, and it provides syntax sugar so you can start being productive right away. You can write perfectly fine production OCaml programs without knowing what a monad is. Some may, but a lot of OCaml devs don’t…

This is correct, and in contrast to Haskell, where monads are a core part of the language (they are used in the definition of do-notation and list comprehensions) and currently the mainstream way to do IO.

Re: Functor, Applicative, and Monad

#34

Post by nacc »

Being someone who is still struggling with these concepts, I like this tutorial because at least it doesn't use the common list/maybe/state to illustrate the concepts. Somehow I feel these concepts are so abstract - unless one is well versed in category theory, maybe only a data approach can prevent people from overfitting these concepts to specific examples.

I would really hope to see a tutorial that have a diverse set of examples and just fmap each example with a light explanation of say, what is a monad in this code and what is not, and because it's a monad we can do this.

Essentially the tutorial can just train a classifier in one's head, and with a nice set of examples maybe the brain can learn a general representation of concepts for the classifier ...

Re: Functor, Applicative, and Monad

#35

Post by jasim »

wh0knows wrote: post #17

I don't think this article is very useful. It doesn't adequately provide an introduction to OCaml code (or adequately explain what a given code snipped is doing) and yet frequently defers to just code to explain a concept. It's an unrealistic expectation to expect an unfamiliar reader to simultaneously infer what a particular code snippet is doing then also go a level deeper and understand the concept that is trying…

OCaml (Reason) was my entry point into Typed FP (after a few failed attempts at learning Haskell). The best thing about OCaml is that it allows side-effects, so one can go a long way without having to touch advanced FP.

It is only recently that I've started getting comfortable with concepts cogently explained in this post, so to me it is quite valuable.

As an aside, I think OCaml/Reason/Elm should become the de-facto Typed FP entrypoint for programmers instead of Haskell. That'll help drive more adoption for the paradigm because the ecosystem is a lot more approachable and one wouldn't feel overwhelmed to even begin.

Re: Functor, Applicative, and Monad

#36

Post by weavie »

nacc wrote: post #34

Being someone who is still struggling with these concepts, I like this tutorial because at least it doesn't use the common list/maybe/state to illustrate the concepts. Somehow I feel these concepts are so abstract - unless one is well versed in category theory, maybe only a data approach can prevent people from overfitting these concepts to specific examples. I would really hope to see a tutorial that have a diverse…

I started writing this the other day - https://codersteve.dev/post/refactoring-to-monads/

It's just a start, but maybe it could help.

Re: Functor, Applicative, and Monad

#37

Post by uryga »

there's an equivalent definition of Applicative that may be a bit less intimidating:

  class Functor f => Applicative f where
    unit :: f ()
    (**) :: f a -> f b -> f (a,b)
[source - a bit CT heavy](https://stackoverflow.com/a/35013667/5534735)

(i'll be writing the second operation as `××` in some places because of HN asterisk weirdness)

this gives us:

- `unit`, a "template" container with a hole we can fill (by doing `fmap (const myValue) unit`, equivalent to `pure myValue`)

- `fa ×× fb`, to "compose" two Applicative values. this shows how, unlike with Monads, the two computations must be "independent". for example, if IO were only an Applicative, you could do

  print "hello" ** print "world"
but not

  getLine >>= \s ->
   print ("hello, " ++ s)
(where the second computation depends on the string we got in the first one)

it also nicely shows the two ways lists can be an Applicative - `fa ×× fb` can be either the Cartesian product `[(a,b) | a (also, it's kind of like a Monoid, which is neat!)

Re: Functor, Applicative, and Monad

#38

Post by mjlangiii »

nacc wrote: post #34

Being someone who is still struggling with these concepts, I like this tutorial because at least it doesn't use the common list/maybe/state to illustrate the concepts. Somehow I feel these concepts are so abstract - unless one is well versed in category theory, maybe only a data approach can prevent people from overfitting these concepts to specific examples. I would really hope to see a tutorial that have a diverse…

In this series functional concepts are very gently introduced. I feel like it really appreciates the beginners starting point and assumes very little. Is this close to what you want?

https://egghead.io/lessons/javascript-linear-data-flow-with-...

Re: Functor, Applicative, and Monad

#39

Post by mkl »

harry8 wrote: post #5

Pretty weird that a comment linking a chapter from an oft referred to haskell text is a dead comment here. Surely if the alternate explantion in "Learn You a haskell for great good" is somehow sub-optimal it would be better to explain how rather than kill the comment inside 10 minutes? You see this sort of thing from language warriors fighting silly wars but, yeah, what's wrong with Learn You a Haskell? Why must it b…

It was probably automated. larusso has only made two comments ever, both containing links, so that probably triggered the spam detectors. You can manually resurrect for accidentally dead comments like this by clicking on the comment's time and then clicking "vouch".
Post reply on HN