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

111–120 of 125 posts

Re: Functor, Applicative, and Monad

#111

Post by lalaithion »

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

I believe that you can say "As long as `a` only appears as the last parameter in a higher kinded type, or not as the parameter of any higher kinded type, then you can define a functor over it."

Re: Functor, Applicative, and Monad

#112

Post by 3PS »

pdpi wrote: post #57
mnsc wrote: post #28

Earlier quoted context omitted.

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

A question. Does map-reduce assume a commutative monoid, or does it need to order the output of map?

Edit: seems like it's the latter.

Re: Functor, Applicative, and Monad

#113

Post by kccqzy »

mavelikara wrote: post #106
kccqzy wrote: post #32

Earlier quoted context omitted.

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

That's actually what I meant: using both the name of the type to figure out what it does. I'm not claiming there's a single implementation given the type. Indeed I don't think that's possible in any signature that's not totally just type variables; here we have Bool and [] as base types so there are operations on them that the function can perform by baking in knowledge of these two types.

Re: Functor, Applicative, and Monad

#114

Post by kccqzy »

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

Definitely learning Haskell as the first language can make it easier to get used to things, but I don't generally agree with C as "poisonous" to one's mind. My last big project written in C was writing a hypervisor, and honestly using C in this context is rather appropriate.

Re: Functor, Applicative, and Monad

#115

Post by kccqzy »

contravariant wrote: post #64
hope-striker wrote: post #33

Earlier quoted context omitted.

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.

By this definition Monads are also a core part of C#, they're not used to do IO but the async/await, IEnumerable, null-safe operators ('?.') are all implementations of Monads ( not by coincidence), and above all you have the Linq syntax that you can extend to all of them and any other Monads you care to define. Yet I imagine most C# programmers have little to no formal understanding of Monads (although quite a few pr…

That's true, it's just that it's culturally inappropriate to use the full power of monads in C# outside specific scenarios like Linq.

Re: Functor, Applicative, and Monad

#116

Post by TheAsprngHacker »

_bxg1 wrote: post #107
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.

The OCaml type 'a * 'b is the equivalent of the Haskell type (a, b). This type is known as the Cartesian product type, and it's written with a multiplication symbol in type theory (hence the asterisk in OCaml syntax).

The product type is the type of pairs. It's definition is

    x : A
    y : B
    --------------
    (x, y) : A * B
meaning that if x has type A and y has type B, then (x, y) has type A * B.

- Product type on Wikipedia: https://en.wikipedia.org/wiki/Product_type - Product type on the nLab (which is a math-heavy resource): https://ncatlab.org/nlab/show/product+type

Re: Functor, Applicative, and Monad

#117

Post by contravariant »

kccqzy wrote: post #115
contravariant wrote: post #64

Earlier quoted context omitted.

By this definition Monads are also a core part of C#, they're not used to do IO but the async/await, IEnumerable, null-safe operators ('?.') are all implementations of Monads ( not by coincidence), and above all you have the Linq syntax that you can extend to all of them and any other Monads you care to define. Yet I imagine most C# programmers have little to no formal understanding of Monads (although quite a few pr…

That's true, it's just that it's culturally inappropriate to use the full power of monads in C# outside specific scenarios like Linq.

Well that really depends on who's working on it. In my opinion Linq isn't so much the only appropriate way to use monads but rather the most convenient way to demonstrate their full power.

Re: Functor, Applicative, and Monad

#118

Post by verttii »

sullyj3 wrote: post #79
notfashion wrote: post #62

Earlier quoted context omitted.

This is misleading. There's no place in the specification of Haskell that specifically defines monads as part of the language. They aren't a language feature. They are a pattern which happens to be expressible in Haskell, and which is supported by libraries: "Haskell's built in support for monads is split among the standard prelude, which exports the most common monad functions, and the Monad module, which contains l…

Is do notation a language feature?

it's syntactic sugar

Re: Functor, Applicative, and Monad

#119

Post by hope-striker »

contravariant wrote: post #64
hope-striker wrote: post #33

Earlier quoted context omitted.

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.

By this definition Monads are also a core part of C#, they're not used to do IO but the async/await, IEnumerable, null-safe operators ('?.') are all implementations of Monads ( not by coincidence), and above all you have the Linq syntax that you can extend to all of them and any other Monads you care to define. Yet I imagine most C# programmers have little to no formal understanding of Monads (although quite a few pr…

Sorry, I'm only vaguely familiar with C#, but maybe you're right, if they get sugar in the form of LINQ syntax. But regarding async/await, (?.), etc., a language doesn't have special support for vector spaces just because it has many vector spaces in it - and every language has many vector spaces in it.

Re: Functor, Applicative, and Monad

#120

Post by unhammer »

unhammer wrote: post #63
mnsc wrote: post #28

Earlier quoted context omitted.

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

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…

too late to edit, but that should look like

    (+1)  Just 1 → Just 2 

    (+1)  getIntFromThatUserThatOnlyTypes1 → IO 2

    (+1)  [1,2] → [2, 3]

    ((+1)  ask) 1 → 2
and

    take  Just 2  Just "abc" → Just "ab"
as if the operator line noise wasn't bad enough already :)
Post reply on HN