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

181–190 of 241 posts

Re: Monads are monoids in the category of endofunctors

#181

Post by tome »

tinco wrote: post #176
tome wrote: post #170

Earlier quoted context omitted.

Sure, synchronous XHTMLHttpRequest.send() is an example https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequ... Certainly it's not idiomatic but that's not lmm's point. The point is that it's possible . In Haskell it's not possible.

Sure it's possible, you can use unsafePerformIO just fine in Haskell. It's idiomatic to not use it, just like it's idiomatic to not use synchronous I/O in JavaScript. Imo it's also not really interesting to talk about non idiomatic use of a language but I guess we disagree there.

It seems to me that there is a qualitative difference between having synchronous HTTP requests in the JavaScript standard library and having access to System.IO.Unsafe.unsafePerformIO in Haskell. Still, I take your point that in theory JavaScript could remove all synchronous I/O side effecting functions and replace them with continuation-based ones.

Anyway, we've wandered pretty far off the main thread, which wasn't mine to begin with, so I'll let lmm take up the discussion again if he wants.

Re: Monads are monoids in the category of endofunctors

#182

Post by skocznymroczny »

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?

It's tricky with functional programming. It's like reading SICP, and after a lot of effort, y-combinators and stuff, the outcome is like "See? Thanks to this invention, we can easily pass multiple parameters into a function". Which is fun, but not anything that will impress a non-functional programming user.

Re: Monads are monoids in the category of endofunctors

#183

Post by pjc50 »

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

> 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 - among many in those circles - a lack of interest in connecting the very simple dots that would allow masses of people to understand these concepts)

This is why people say "a monad is a monoid in the Category of endofunctors" as a joke whenever anyone posts an unnecessarily complicated explanation. This is the biggest and most visible flashpoint between people who don't understand, and the people who don't understand why they don't understand and think that defining things in terms of other things that you also don't understand is a viable strategy.

Re: Monads are monoids in the category of endofunctors

#184

Post by momentoftop »

Twisol wrote: post #169
momentoftop wrote: post #142

Earlier quoted context omitted.

Good points. But I'd note that Haskell's infrastructure around Functor isn't typical of functional languages. Specifically in Haskell, I think it's pretty important to have an idea what functors, monoids and monads are, because these are typeclasses that you will almost certainly be using at some point. Not all functional languages have typeclasses or an alternative and convenient way to express these concepts, and i…

I agree with your overall point, but I want to dig in on this bit: > Not all functional languages have typeclasses or an alternative and convenient way to express these concepts, and in those, it's not so important to understand these notions abstractly. This is true only in an especially strict sense. Haskell's typeclasses provide two basic mechanisms: one for associating a dictionary of data with a type, and one fo…

It's certainly possible to express some of these ideas in other languages, but implementations are nowhere near as ubiquitous or idiomatic as in Haskell, where they pervade the standard library and most people's code. And I'd argue that's because the ergonomics of the solutions in other languages don't come close to those of Haskell's. Furthermore, there appear to be limits to how far you can take them.

For example, Java lacks higher-kinding which is needed to define a monad abstractly. This can be got cheated around using ideas from this paper (0), but it costs a cast which the compiler cannot prove safe. This is the basis for things like the arrow library in Kotlin, which while impressive, doesn't compare to the ergonomics of Haskell and still misses a bunch of standard abstractions such as Traversable, which are part of the mentioned infrastructure that makes monads (1) so useful to Haskellers.

[0] https://ocamllabs.io/higher/lightweight-higher-kinded-polymo...

[1] applicative functors more generally.

Re: Monads are monoids in the category of endofunctors

#185

Post by contravariant »

Sniffnoy wrote: post #10
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? And an endofunctor is just one of those where the argument type and return type are the same? No. I don't know why the article talks about ordinary functions on values as if they're functors. They're not (or at least, not in a nontrivial way; you could come up with a silly, useless way in which they are, but that's not what anyone's talking about). Sorry, but it's the…

Mathematically the main thing stopping it from being a function is that categories are typically too big to be a set. Otherwise they're pretty much the same as a function.

The whole type thing is just something Haskell does, it's not something that's meaningful for general categories.

Re: Monads are monoids in the category of endofunctors

#186

Post by OJFord »

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.

> fmap (f . g) == fmap f . fmap g

Can you give an example where that doesn't follow from `map identity f == f`? Assuming of course `f` .. is what I think is called 'pure'? i.e. is deterministic on its input arguments.

Re: Monads are monoids in the category of endofunctors

#187

Post by lkitching »

devit wrote: post #94
epolanski wrote: post #40

Earlier quoted context omitted.

That's actually the only correct part of the blog, arrays form monoids via concatenation and empty arrays. That's algebra tho, which is very relevant to functional programming (monoids capture the essence of composition) in general, but not the right monoids in category theory.

Of course they form a monoid with concatenation, but it's not the monoid that makes the monad (which should be pretty obvious since concatenation is not used in the monad operations for arrays).

The type of join for arrays is Array (Array a) -> Array a which should concatenate all the inner arrays together.

Re: Monads are monoids in the category of endofunctors

#188

Post by mhitza »

Littlebigo wrote: post #109
6nf wrote: post #60

Earlier quoted context omitted.

You have to start with the 'simplified but not technically perfectly correct' and then add in the nuances to get to the real point. Starting with words like 'functors' that most software engineers today will not be able to define is not useful.

The article is likely aimed at intermediate-ish FP programmers, though, not people with no prior knowledge. (Although I suspect it is an example of "learning by teaching", since it is wrong on many counts.) Learn You a Haskell mentions functors in chapter 8 and teaches them properly in chapter 11. http://learnyouahaskell.com/making-our-own-types-and-typecla...

In my opinion Monads at this point should be considered a beginner Haskell concept.

Regardless of how LYAH chooses to order things, (when have you used a Zipper last time?), they are too essential to any beginner Haskell program.

In my opinion we need a new imperative first approach to Haskell teaching, to develop intuition on monads quickly.

Re: Monads are monoids in the category of endofunctors

#189

Post by thinkharderdev »

contravariant wrote: post #185
Sniffnoy wrote: post #10

Earlier quoted context omitted.

> 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? No. I don't know why the article talks about ordinary functions on values as if they're functors. They're not (or at least, not in a nontrivial way; you could come up with a silly, useless way in which they are, but that's not what anyone's talking about). Sorry, but it's the…

Mathematically the main thing stopping it from being a function is that categories are typically too big to be a set. Otherwise they're pretty much the same as a function. The whole type thing is just something Haskell does, it's not something that's meaningful for general categories.

Not really, mathematically a functor is really two "functions," one mapping objects to objects and one mapping morphisms to morphisms, along with some conditions that make sure the functor is "structure preserving." It is fundamentally a type level construct because, as it is applied to programming, the category in question is the category of types (which is not technically a category due to the halting problem but we sort of hand-wave that away).

Re: Monads are monoids in the category of endofunctors

#190

Post by thinkharderdev »

zabzonk wrote: post #41
jkhdigital wrote: post #20

Earlier quoted context omitted.

Functors are type constructors, not functions (which map values). But you could be forgiven the misunderstanding, because it is easy to trip over this distinction given the identical syntax. So, to make this absolutely clear, a monad is a type constructor in functional programming. This is why I personally prefer the more “creative” explanations of monads, because they attempt to explain what the monad is doing to th…

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

A function that take one type and gives you another type. So (in Java for example) you have a generic type such as List. But that is not a really a type because you can't have a value of the generic type. It is actually a type constructor, you can give it another type (say String) and it will give you a type List which can actually be instantiated to a value. So in the context of programming languages it is just a fancy word for a generic or parametric type.
Post reply on HN