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

Monads are monoids in the category of endofunctors

sambernheim.com

Post reply on HN
Print view View original

71–80 of 241 posts

Re: Monads are monoids in the category of endofunctors

#71

Post by [deleted] »

lmm wrote: post #26
brundolf wrote: post #5

Wait, a functor is just a pure unary function? And an endofunctor is just one of those where the argument type and return type are the same? This could have been explained to me years ago, in five minutes? Sometimes it makes me mad that so much confusion (and as another commenter put it, gatekeeping) has been sown in FP circles through the invention of pointlessly-obfuscated terminology for everything (and through -…

> Wait, a functor is just a pure unary function? No. > And an endofunctor is just one of those where the argument type and return type are the same? Yes - "endo" means that in general. E.g. endomorphism. > Sometimes it makes me mad that so much confusion (and as another commenter put it, gatekeeping) has been sown in FP circles through the invention of pointlessly-obfuscated terminology for everything (and through -…

[deleted]

Re: Monads are monoids in the category of endofunctors

#72

Post by 6nf »

Twisol wrote: post #66
6nf wrote: post #64

Earlier quoted context omitted.

What makes a type constructor a functor, what's the difference

In particular, a functor is a type constructor F together with a higher-order function deriving transformations `F T -> F S` given a transformation `T -> S`, subject to some semantic requirements. This is the `map` or `fmap` people refer to as defining the functor. Unfortunately, due to abuse of notation, the type constructor isn't given much focus. But it's true that "type constructor" is the first conceptual hurdle…

See this is exactly the point where FP fans lose the rest of us.

Re: Monads are monoids in the category of endofunctors

#73

Post by catgary »

Twisol wrote: post #66
6nf wrote: post #64

Earlier quoted context omitted.

What makes a type constructor a functor, what's the difference

In particular, a functor is a type constructor F together with a higher-order function deriving transformations `F T -> F S` given a transformation `T -> S`, subject to some semantic requirements. This is the `map` or `fmap` people refer to as defining the functor. Unfortunately, due to abuse of notation, the type constructor isn't given much focus. But it's true that "type constructor" is the first conceptual hurdle…

Type constructor that lifts to functions is even a pretty intuitive (ahistorical) intuition for “functor”.

Re: Monads are monoids in the category of endofunctors

#74

Post by xigency »

lmm wrote: post #49
void_mint wrote: post #33

Earlier quoted context omitted.

> The precise terminology is vital; it's how we avoid these errors when talking about this very abstract stuff. Given that the OP is very wrong, precisely because of the kind of attitude you've taken here, I hope you'll take this opportunity to reconsider your views. Your behavior is precisely the behavior that someone new to FP would see and say "Hard pass on that", which goes into the greater problem of FP being un…

Communication is a two-way street. When someone is making an effort to learn, most FP advocates will happily make an effort to teach. But someone who comes in with guns blazing doesn't get to complain about being met with hostility, and if telling someone they're wrong when they're wrong is gatekeeping then it's a kind of gatekeeping that we need.

Being a teacher is a labor of love. There’s nothing wrong with a student coming in with any attitude.

This attitude justifying gatekeeping reminds me of Stack Overflow - mods tired of seeing the same wrong questions asked. But it’s a Q&A site and the purpose is for people to get answers to their questions.

Re: Monads are monoids in the category of endofunctors

#75

Post by hikarudo »

brundolf wrote: post #59
hikarudo wrote: post #53

Earlier quoted context omitted.

A type constructor is something that takes a type and gives you a new type. For example, in C, if you have any type Foo, the pointer operator * will give you a new type Foo*. Another example: in Haskell, Maybe is a type constructor, since it takes a type parameter a (Maybe a). So 'Maybe' is a type constructor, but 'Maybe Int' is a type. So a type constructor is like a function, but it operates on types, not on values…

So this is a perfect example of how things could be better-explained to the average developer via analogy: "You can think of a type constructor like a generic type, particularly the way those work in languages like TypeScript" Edit: The C example was added after my initial comment, and is better than nothing, though I'd tend to say the pointer example is a bit of a weird one to go with. Of course intuitiveness is rel…

Good point. A generic type is a great example of a type constructor.

Re: Monads are monoids in the category of endofunctors

#76

Post by dwohnitmok »

opnitro wrote: post #56
tantalor wrote: post #42

Earlier quoted context omitted.

> why a Functor is slightly more than just a Mappable Explain that again?

A Mappable would be anything that has a `map` function. A `Functor` is a something that has a `map` function _AND_ obeys the rule that calling `map` with the identity function produces the same result. ie: say I have some value `f` that is a functor. If I call `map identity f` I should always get back `f`. The mere existence of a `map` function doesn't imply this law holds. The identity function always returns it's a…

> They also need to preserve composition.

I didn't state this because this generally comes for free, assuming no shenanigans such as runtime type reflection/type-casing (but in that case all laws go out the window). In particular in Haskell (which is what I assume you're coming from given fmap and your ML-ish syntax) this is a superfluous law. If a type constructor's `fmap` obeys the identity law, it must obey the composition law.

Re: Monads are monoids in the category of endofunctors

#77

Post by catgary »

6nf wrote: post #72
Twisol wrote: post #66

Earlier quoted context omitted.

In particular, a functor is a type constructor F together with a higher-order function deriving transformations `F T -> F S` given a transformation `T -> S`, subject to some semantic requirements. This is the `map` or `fmap` people refer to as defining the functor. Unfortunately, due to abuse of notation, the type constructor isn't given much focus. But it's true that "type constructor" is the first conceptual hurdle…

See this is exactly the point where FP fans lose the rest of us.

It’s a type constructor that extends to functions. It’s a functor.

Re: Monads are monoids in the category of endofunctors

#78

Post by lupire »

tantalor wrote: post #42
dwohnitmok wrote: post #15

Earlier quoted context omitted.

> a functor is just a pure unary function? No, although a pure unary function could be viewed as a functor, the other direction doesn't hold. The common FP definition of a functor is anything that supports a notion of `map` (subject to the restriction that `map`ping the identity function does nothing, this is why a Functor is slightly more than just a Mappable). This is not a unary function although map takes a unary…

> why a Functor is slightly more than just a Mappable Explain that again?

Well it depends how you define Mappable, but...

Pythonish pseduocode:

BadFunctor is a List (of generic type) with

    def badMap(function, stuff) :
    return [map(function, stuff) + map(function, stuff)]
That's a Mappable, but not a Functor.

Re: Monads are monoids in the category of endofunctors

#79

Post by Twisol »

lmm wrote: post #25
chrisseaton wrote: post #11

Earlier quoted context omitted.

> Wait, a functor is just a pure unary function? And guess what another name for a unary functions is... 'monadic'.

Which means something completely different from the use of "monadic" here.

To expand on this, because it's actually fascinating...

Functors capture a particular pattern of "pipelining": a series of operations A -> B, B -> C, etc. can be uniformly assembled in the context of any arbitrary functor F, ultimately giving a unary pipeline `F A -> F C`. (I won't detail what this means completely; I'm going for a gut instinct in the following bit.)

But what if you have a binary function, (A1, A2) -> B? Functors only let you assemble unary operators; there's no provision for taking the outputs of two pipelines and weaving them together. Applicatives (or, "monoidal functors") give you an additional operator that let you turn a pair `(F A1, F A2)` into a contextual pair `F (A1, A2)`, which can then be fed to a unary pipeline. (In terms of pipe shapes, it's a Y-bend.)

Monads extend this in a less interesting way, but in the sense of "monadic" as "unary", functors are actually more monadic than monads!

Re: Monads are monoids in the category of endofunctors

#80

Post by rizky05 »

lmm wrote: post #49
void_mint wrote: post #33

Earlier quoted context omitted.

> The precise terminology is vital; it's how we avoid these errors when talking about this very abstract stuff. Given that the OP is very wrong, precisely because of the kind of attitude you've taken here, I hope you'll take this opportunity to reconsider your views. Your behavior is precisely the behavior that someone new to FP would see and say "Hard pass on that", which goes into the greater problem of FP being un…

Communication is a two-way street. When someone is making an effort to learn, most FP advocates will happily make an effort to teach. But someone who comes in with guns blazing doesn't get to complain about being met with hostility, and if telling someone they're wrong when they're wrong is gatekeeping then it's a kind of gatekeeping that we need.

You remind me of sheldon.
Post reply on HN