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

61–70 of 241 posts

Re: Monads are monoids in the category of endofunctors

#61

Post by Phaedor »

void_mint wrote: post #33
lmm wrote: post #26

Earlier quoted context omitted.

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

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

So you would say the same for programming in general then? Should programmers not use the word "function" because that word is foreign to non-programmers and might push them away?

Re: Monads are monoids in the category of endofunctors

#62

Post by dwohnitmok »

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?

In theory you could have something like

  interface Mappable {
    // Interfaces don't quite cut it here, because you want 
    // `map` to return a specific implementation of 
    // Mappable, not a general Mappable, but we'll let that 
    // slide for the purposes of exposition
    map(f: A => B): Mappable
  }

  class MyWeirdMappable(val myCounter: Int, val myValue: A) implements Mappable {

    // Notice the return type is MyWeirdMappable not 
    // Mappable, as mentioned earlier
    map(f: A => B): MyWeirdMappable {
      if (myCounter == 0) {
        return this
      } else {
        return MyWeirdMappable(myCounter + 1, f(myValue))
      }
    }
  }
Although this fulfills the contract of `Mappable`, it's not a `Functor`, because `map(identity)` doesn't always return the same (or equivalent) `MyWeirdMappable`.

Re: Monads are monoids in the category of endofunctors

#63

Post by zabzonk »

hikarudo wrote: post #53
zabzonk wrote: post #41

Earlier quoted context omitted.

> a monad is a type constructor Now explain what a "type constructor" is, otherwise these words are worthless.

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…

> the pointer operator *

Do you mean declarator?, As in:

     Foo * f;    // f is a pointer to a Foo
The operator dereferences something - it certainly does not create a new type. And neither does the above - the concept of pointers to addressable types is innate to the C and C++ type systems - if you create a type Foo, you get pointers to Foo for free.

Re: Monads are monoids in the category of endofunctors

#64

Post by 6nf »

catgary wrote: post #57
6nf wrote: post #48

Earlier quoted context omitted.

>Functors are type constructors So why can't we just call the damn things 'Type constructors'?

Not every type constructor is a functor.

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

Re: Monads are monoids in the category of endofunctors

#66

Post by Twisol »

6nf wrote: post #64
catgary wrote: post #57

Earlier quoted context omitted.

Not every type constructor is a functor.

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.

Re: Monads are monoids in the category of endofunctors

#67

Post by epolanski »

brundolf wrote: post #52
epolanski wrote: post #47

Earlier quoted context omitted.

What do you mean?

These concepts are usually explained via first-principles definitions, and they are usually opaque and unapproachable for most people. That's not a coincidence.

There's nothing in this list: - Algebra: Semigroups, Monoids. - Algebraic Data Types: product and sum types. - Functor, Applicative, Monad

which covers basically all the fundamentals to be proficient in functional programming that has definitions that are opaque and unapproachable. And all of those have very simple examples, both in real life and especially programming. But definition has to come first, or you have this great mass of people that do not understand what they talking about even when they blog about it.

If you can take your time to understand that a type constructor (and take the time to see what it is) and a map function form a pair called functor, you are equipped to learn about monads.

It's not rocket science, but yes, it requires a bit of studying and learning, which is what people don't want to hear, and instead choose the long road of contrived example-driven, inaccurate and confusing blog posts.

Re: Monads are monoids in the category of endofunctors

#68

Post by hikarudo »

zabzonk wrote: post #63
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…

> the pointer operator * Do you mean declarator?, As in: Foo * f; // f is a pointer to a Foo The operator dereferences something - it certainly does not create a new type. And neither does the above - the concept of pointers to addressable types is innate to the C and C++ type systems - if you create a type Foo, you get pointers to Foo for free.

You are correct, my mistake.

Re: Monads are monoids in the category of endofunctors

#69

Post by brundolf »

Phaedor wrote: post #61
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…

So you would say the same for programming in general then? Should programmers not use the word "function" because that word is foreign to non-programmers and might push them away?

Some terms are used for radically new concepts with no analogue, some terms refer almost exactly to concepts people already know, and some terms refer approximately to concepts people already know (and could be explained as "like X but with these differences")

For example: I might explain the programming concept of a function as "like the equations you remember from math class" (for pure functions) or "like a recipe" (for imperative functions).

I would also not, for example, make up a totally new term for a concept people already know about that just happens to be in the context of my new system of ideas. This actually comes up a lot in my day to day software engineering work: I avoid creating new abstractions in general, and when I do I strongly avoid introducing new terminology in the naming, and when I do I document and explain it to death in the comments, using analogies wherever possible.

There are lots of opportunities where I could come up with a whole new concept with a beautiful new name that nobody understands, and I explicitly choose not to.

Re: Monads are monoids in the category of endofunctors

#70

Post by gopiandcode »

lmm wrote: post #28
Tade0 wrote: post #3

Functional programming is subject to an enormous amount of gatekeeping. Kudos to the author for pushing that gate wide open.

Author is completely wrong, and as such is a perfect demonstration of why that "gatekeeping" (actually just being precise and correct) is necessary.

This. By that same virtue (although admittedly with far greater stakes), I wonder if the GP would call safety regulations on civil engineering a similar kind of "gatekeeping" in need of "disruption".
Post reply on HN