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

101–110 of 125 posts

Re: Functor, Applicative, and Monad

#101

Post by verttii »

leshow wrote: post #94
jasim wrote: post #35

Earlier quoted context omitted.

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…

I learned typed FP from Haskell, coming from JS, and I'm glad I started there. It was a bit of a slog, but there are some wonderful books out there. I don't think we should discount the amount of pedagological resources that are available in the language. My favorite is the "First Principles" book. As a side effect, I found that once I had learned most of Haskell (minus some of the language extensions aimed at type l…

What would you say are some of the main benefits you gained with your journey with Haskell, beyond coming across a lot of abstract concepts?

I'm struggling to justify spending more time on picking up Haskell myself as I can't see clearly what's at the end of that tunnel.

Re: Functor, Applicative, and Monad

#102

Post by whateveracct »

BucketSort wrote: post #22
whateveracct wrote: post #12

Earlier quoted context omitted.

My favorite part about Haskell is how you can know literally nothing about the domain and make meaningful changes to programs regardless thanks to local reasoning. That's really one power of functor/applicative/monad - if you understand their interfaces, you can work with new unfamiliar types that have these instances without much effort at all.

It's amazing. No one could ever do something like this with an imperative language!

Nobody ever said that :)

Although abstracting over this stuff isn't possible in any imperative language unless Scala or maybe advanced C++ template count. But that isn't due to their imperative nature exactly.

But local reasoning is very hard to count on in most other languages - that's for sure. It's easier to just run a VM in your head.

Re: Functor, Applicative, and Monad

#103

Post by moomin »

TheAsprngHacker wrote: post #56
antisemiotic wrote: post #55

Earlier quoted context omitted.

Think `data Foo a = Foo (a -> Bool)`, pardon my Haskell. A function `map :: (a -> b) -> Foo a -> Foo b` is impossible, however `contramap :: (a -> b) -> Foo b -> Foo a` is fine (just pre-compose the given function with the stored function). Even worse with `data Bar a = Bar (a -> a)`.

Thanks. I know what contravariant functors are, but I haven't used them, so I didn't realize that was what the parent commenter was asking about. You're right, my claim that every type 'a t has a corresponding (covariant) functor is incorrect, and I should either take that out or mention contravariant functors.

It’s even worse than that. Consider

    data Foo a = Foo (a -> a)
This admits neither Functor nor Contravariant. Sadly all you can say is “If you can map, it’s a functor.”

I always end up finding out more about any subject I actually publish a post about when people read it...

Re: Functor, Applicative, and Monad

#104

Post by dllthomas »

zeugmasyllepsis wrote: post #97
dllthomas wrote: post #92

Earlier quoted context omitted.

"Conclusively" is probably a little strong. You're relying not just on the type, but also the name - the type alone isn't enough here, even without resorting to bottom, and even when requiring every piece be meaningfully used. For instance, with the same type we can write: doubleIf :: Applicative m => (a -> m Bool) -> [a] -> m [a] doubleIf f values = case values of [] -> pure [] x:xs -> prepend x f x doubleIf f xs wh…

Maybe a simpler way to illustrate this is two different functions built off of filter: `keep`: Given a predicate and a collection, filter the collection to retain only items for which predicate evaluates to true. `discard`: Given a predicate and a collection, filter the collection to discard items for which the predicate evaluates to false. These are two very reasonable functions that would have the exact same signat…

Honestly, you could reasonably call either of those "filter" :D

Re: Functor, Applicative, and Monad

#105

Post by TheAsprngHacker »

moomin wrote: post #103
TheAsprngHacker wrote: post #56

Earlier quoted context omitted.

Thanks. I know what contravariant functors are, but I haven't used them, so I didn't realize that was what the parent commenter was asking about. You're right, my claim that every type 'a t has a corresponding (covariant) functor is incorrect, and I should either take that out or mention contravariant functors.

It’s even worse than that. Consider data Foo a = Foo (a -> a) This admits neither Functor nor Contravariant. Sadly all you can say is “If you can map, it’s a functor.” I always end up finding out more about any subject I actually publish a post about when people read it...

The other person also mentioned this. It's called invariance. There's also a fourth variance: https://www.benjamin.pizza/posts/2019-01-11-the-fourth-type-...

Re: Functor, Applicative, and Monad

#106

Post by mavelikara »

kccqzy wrote: post #32
mavelikara wrote: post #11

Earlier quoted context omitted.

> 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 inf…

> 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.

The function below matches the signature of filterM for List monad, but does not do anything remotely similar to what you described.

    foo :: (Int -> [Bool]) -> [Int] -> [[Int]]
    foo f xs = 
      case bool of 
        [True] -> []
        _  -> [xs]
      where bool = f $ length xs
This is a contrived example, but I think a large part of your guess on what filterM does comes from the word "filter" in its name. This isn't any different from other mainstream programing language, so it is not a ding on Haskell.

Re: Functor, Applicative, and Monad

#107

Post by _bxg1 »

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…

As someone who's only spent about an hour reading an intro to Haskell (and none reading about OCaml), I was able to mostly get the gist of what was being said. Not completely. I had to look up the * operator (effectively a comma between arguments, as opposed to a currying arrow), but I would consider the article to have been useful, even if it could've been more useful.

Re: Functor, Applicative, and Monad

#108

Post by _bxg1 »

I've always understood intuitively the existence of .map(), .reduce(), and .flat() in JavaScript, but .flatMap() felt like a weirdly arbitrary combination of two of them. Now it makes sense!

Re: Functor, Applicative, and Monad

#109

Post by TheAsprngHacker »

thedanbob wrote: post #98
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…

I majored in math so I was already familiar with some of the concepts, but OCaml is so different from any language I’ve worked in I couldn’t understand how any of it was being applied.

I can try to explain this to you from a math perspective, if you want, but I need to know your math background. Are you familiar with the lambda calculus and its relationship to category theory?

Re: Functor, Applicative, and Monad

#110

Post by TheAsprngHacker »

moomin wrote: post #103
TheAsprngHacker wrote: post #56

Earlier quoted context omitted.

Thanks. I know what contravariant functors are, but I haven't used them, so I didn't realize that was what the parent commenter was asking about. You're right, my claim that every type 'a t has a corresponding (covariant) functor is incorrect, and I should either take that out or mention contravariant functors.

It’s even worse than that. Consider data Foo a = Foo (a -> a) This admits neither Functor nor Contravariant. Sadly all you can say is “If you can map, it’s a functor.” I always end up finding out more about any subject I actually publish a post about when people read it...

Thank you for pointing out contravariant functors; I have fixed that sentence in my post and credited you.
Post reply on HN