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

51–60 of 125 posts

Re: Functor, Applicative, and Monad

#51

Post by sirclueless »

BucketSort wrote: post #20
kccqzy wrote: post #10

Earlier quoted context omitted.

I have never heard of Euterpea, nor have I seen the rest of your code, but I suggest you refactor your slightly convoluted code like this: notePlayer notes octs dur = musicSeq $ notes octs pure dur Coincidentally, this might be a testament of the power of parametric polymorphism and equational reasoning.

Amazing, thanks! It always amazes me how natural Haskell is for some people. Some seem to see the simplest solution with so little effort while I still struggle with almost embarrassingly simple things. I wish I would have picked up Haskell as my first language, instead my mind was poisoned by C...

I haven't figured out whether the C I learned was poison. I often wish I could intuit Haskell without translating everything to imperative in my head, because of how cleanly many complex things can be expressed. On the other hand, pretty much everything I program has some rough kind of performance constraint in practice and I appreciate how directly I can read the performance characteristics of an imperative program from its control flow.

Re: Functor, Applicative, and Monad

#52

Post by TheAsprngHacker »

uryga wrote: post #37

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 `f…

Huh? I cover this definition in the tutorial, when I discuss OCaml's (and+) operator! Did I gloss over things too quickly?

Re: Functor, Applicative, and Monad

#53

Post by TheAsprngHacker »

moomin wrote: post #46

It turns out that every generic type t has a corresponding map function map : ('a -> 'b) -> 'a t -> 'b t. So how about x : 'w -> Bool?

If there is a function `map : ('a -> 'b) -> 'a t -> 'b t`, and there exists a function `x : 'w -> bool`, then `map x : `'w t -> bool t`. Is this what you were asking?

Re: Functor, Applicative, and Monad

#54

Post by ipnon »

hoseja wrote: post #14

I should learn to read Haskell one of these days. Not today though.

"Learn You a Haskell" is sparse on theoretical foundations. I made it halfway through the book feeling like I only had a superficial understanding of the language. If you are interested in a rigorous or systematic approach I recommend "Haskell Programming from First Principles".

Re: Functor, Applicative, and Monad

#55

Post by antisemiotic »

TheAsprngHacker wrote: post #53
moomin wrote: post #46

It turns out that every generic type t has a corresponding map function map : ('a -> 'b) -> 'a t -> 'b t. So how about x : 'w -> Bool?

If there is a function `map : ('a -> 'b) -> 'a t -> 'b t`, and there exists a function `x : 'w -> bool`, then `map x : `'w t -> bool t`. Is this what you were asking?

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

Re: Functor, Applicative, and Monad

#56

Post by TheAsprngHacker »

antisemiotic wrote: post #55
TheAsprngHacker wrote: post #53

Earlier quoted context omitted.

If there is a function `map : ('a -> 'b) -> 'a t -> 'b t`, and there exists a function `x : 'w -> bool`, then `map x : `'w t -> bool t`. Is this what you were asking?

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.

Re: Functor, Applicative, and Monad

#57

Post by pdpi »

mnsc wrote: post #28
bad_user wrote: post #19

Earlier quoted context omitted.

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…

> Having reusable functions that work just as well on lists, maybe/option, reader, io / promise or what have you means these type classes do a very good job at abstracting over data types. These are the purest forms of abstraction. This is where I get kinda lost. Can you give an example of such a reusable function that works for all these things which does something valuable?

Map-reduce is effectively the fruit of realising that, as long as your processing can be described as a combination of Functor (map) and Monoid (reduce) operations, then you can trivially parallelise your computation by letting the implementation of `map` and `reduce` handle all the parallelism for you.

Re: Functor, Applicative, and Monad

#58

Post by TheAsprngHacker »

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…

In your opinion, is this article less helpful than the functor/monad tutorials that predominantly use Haskell?

Re: Functor, Applicative, and Monad

#59

Post by lonelappde »

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…

It's plainly obvious that the GP poster made no such claim about category theory, and the OP post states several times that category theory is merely tangential to the topic.

Re: Functor, Applicative, and Monad

#60

Post by lonelappde »

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…

Your description means they are design patterns: a technique to solve a problem that appears repeatedly. What trips people up is that monad is a 2nd-level pattern, as can be seen in the type. 'List a' is-a pattern for nondeterminism. 'Maybe a' is-a pattern for handling failure. Instancing 'm a' is a pattern for 'sequencing effects with branching' and also other patterns for various other applications.
Post reply on HN