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

121–125 of 125 posts

Re: Functor, Applicative, and Monad

#121

Post by unhammer »

lmm wrote: post #68
unhammer wrote: post #63

Earlier quoted context omitted.

The simplest but still most versatile one is probably fmap (also knowns as ) which lets you use a function on whatever is inside the burrito: (+1) Just 1 → Just 2 (+1) getIntFromThatUserThatOnlyTypes1 → IO 2 (+1) [1,2] → [2, 3] ((+1) ask) 1 → 2 Want let a function eat several burritos without making a mess? Keep your burritos apart with >: take Just 2 > Just "abc" → Just "ab" etc. You can be quite productive without…

No. If you attempt to write monad-generic code using the burrito analogy you will inevitably write broken code, causing serious problems for other users and/or your future self. Burritos may be a good analogy for some subset of monads, e.g. collections, but they are not a good analogy for monads in general: the function you pass to fmap may be executed now or later, zero, one, or many times, before or after a functio…

Nah, like any bad analogy, it can be stretched :) Once you've moved past the "lies-to-children[1]" version, you can ascend to the real meat of the burrito: https://blog.plover.com/prog/burritos.html

And once you've fully grokked burritos in terms of monads, you can finally reach that zen level where you solve your problems without even a single line of code (because you've started working at the burrito shop instead: http://chrisdone.com/posts/monads-are-burritos ).

[1] https://en.wikipedia.org/wiki/Lie-to-children

Re: Functor, Applicative, and Monad

#122

Post by ernst_klim »

lmm wrote: post #70
lonelappde wrote: post #66

Earlier quoted context omitted.

You can do it in Scala which has powerful type support. The problem with other languages is that they lack the support for the higher order types, so the implementation is dishonest or you have to build up an API (new embedded minilanguage) to express them, which is a lot of work and a distraction. And, the result tends to be very cluttered with syntax junk, as you can see in Scala and Functional Java. Which incident…

OCaml also lacks higher-kinded types. As far as I can tell, anything you can do in OCaml you can also do (perhaps verbosely, though less so in more recent versions) in Java.

OCaml have HKT, it's in the module part of the languiage, it's just verbose.

And OCaml's module language is much more powerful than Java, since module language is a dependently typed language. You can't, say, pass a class including a type for another class in java.

Re: Functor, Applicative, and Monad

#123

Post by moomin »

TheAsprngHacker wrote: post #110
moomin wrote: post #103

Earlier quoted context omitted.

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.

Oh that’s much more extensive. Like the link to Julie’s work.

Re: Functor, Applicative, and Monad

#124

Post by mlevental »

bad_user wrote: post #19
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,…

The point is that Monad, Applicative and Functor are well defined interfaces with laws (properties) you can count on. They are in fact much better, more precisely defined than classic design patterns. And in expressive programming languages (that support higher kinded types or that at least let you encode such types) you can also describe generic code that works over any applicative or monadic type. Having reusable f…

>The point is that Monad, Applicative and Functor are well defined interfaces with laws (properties) you can count on.

except you can't because you can have unlawful implementations.

Re: Functor, Applicative, and Monad

#125

Post by leshow »

verttii wrote: post #101
leshow wrote: post #94

Earlier quoted context omitted.

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.

I love Haskell, I find it a joy to write. If you don't really enjoy it then there isn't much reason to spend time on it. It's probably not going to help you with employment. As a side benefit, it's helped me solidify many PLT and CS concepts. That's enough for me to see value in it.
Post reply on HN