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

151–160 of 241 posts

Re: Monads are monoids in the category of endofunctors

#151

Post by yawaramin »

sfsffgrgd wrote: post #130
yawaramin wrote: post #121

> This phrase is the cheeky line to (somewhat) formally define the monad It's actually a satirical joke[1] that people started taking way too seriously. Honestly, imho people should never use this line when explaining monads. It's like saying 'C is a purely functional programming language!' because Conal Elliott, around the same time, wrote[2] a parodic blog post making fun of purely functional programming zealots. […

Come onnn. The phrase that forms the title of this post is very close to what (CT giant) Saunders Mac Lane wrote, quite seriously. In fact it's missing the word "just"! Iry was inspired by Mac Lane, but you seem to have got the wrong end of the stick on the actual status of these words. See, for example, https://stackoverflow.com/a/3870310/14768587

I am obviously talking in the context of programming, not abstract math ;-)

In this context, it's quite obvious that I am correct. Programmers around the world wouldn't have been perplexed for a decade because of a labyrinthine quote from Mac Lane's Categories for the Working Mathematician.

Re: Monads are monoids in the category of endofunctors

#152

Post by yawaramin »

BrissyCoder wrote: post #141
yawaramin wrote: post #120

Earlier quoted context omitted.

Ever use Facebook? WhatsApp? Discord? Telephones? Docker? Amazon EC2? Bought something in a Walmart store or on their websites? etc. etc. Some of their core, critical parts are written in functional programming languages. Just because you don't see FP out in the wild being conspicuous, doesn't mean it's not there ;-)

Which parts in particular? Genuinely curious.

- Facebook: spam filter implemented in an efficient data access language/tool called Haxl: https://engineering.fb.com/2014/06/10/web/open-sourcing-haxl...

- WhatsApp: famous for being written in Erlang, a functional programming language, and processing more messages a day than the entire global SMS network with a team of 50 backend engineers

- Discord: handling extreme amounts of chat/call traffic using Elixir, another functional programming language based on the same tech as Erlang

- Telephones: telephone switches from Ericsson (and in fact, internet switches from Cisco) use Erlang

- Docker: core virtualization component for macOS (hyperkit) written in OCaml

- Amazon EC2: another core virtualization component of all computes, parts of the Xen hypervisor, written in OCaml

Re: Monads are monoids in the category of endofunctors

#153

Post by flebron »

I've always found the definition of monoid objects in a category of endofunctors to be tougher to grasp than the Kleisli-category definition of a monad, at least if one is being formal about "monoid object", and checking that the necessary diagrams commute.

Given a functor m of Hask, we define a squiggly arrow ~>, where a ~> b is a -> m b. If these ~> are the arrows in some category (which we call the Kleisli category for m), then we call m a monad. Here id :: a ~> a in that category is what we call return :: a -> m a, and the composition (.) :: (b ~> c) -> (a ~> b) -> (a ~> c) in that category is used to create bind :: m a -> (a -> m b) -> m b, where bind x f = (.) f (const x) (return ()), where (.) is the squiggly arrow (.) we just mentioned. Bind is what's spelled >>= in Haskell, and is what's behind the "x <- f" do-notation.

Re: Monads are monoids in the category of endofunctors

#154

Post by lmm »

tinco wrote: post #135
lmm wrote: post #124

Earlier quoted context omitted.

> There is literally no side effects except for application state mutation from the perspective of a JavaScript function (if you disregard the few deprecated synchronous API's). That's a pretty big "except" - there are no side effects except for all the side effects (and there's nothing unique about JavaScript there, that much is the same as almost any other language). JavaScript's approach to I/O, like most language…

> That's a pretty big "except" - there are no side effects except for all the side effects (and there's nothing unique about JavaScript there, that much is the same as almost any other language) It's not like Haskell doesn't have those either though, I don't think it's a very big except. Discussing synchronous I/O in JavaScript is not interesting, were not littering our Haskell with unsafePerformIO either. > JavaScri…

> No, this is just not true, are we using the same JavaScript? JavaScript's functions change only based on modified application state, not on any other side effect.

If you read some file (or remote URL) multiple times, you may get different data each time. Haskell makes "functions" with this property clearly distinct from regular functions. Most languages, including JavaScript, don't. That's what matters, not whether I/O is synchronous or not.

> Sure, in the current Haskell that's true. In previous iterations of Haskell this wasn't always the case though

That may or may not be technically true but it's not really informative or relevant - Haskell has had monadic I/O for over 20 years and the overwhelming majority of Haskell users have never used any other kind.

Re: Monads are monoids in the category of endofunctors

#155

Post by lmm »

void_mint wrote: post #125
lmm wrote: post #122

Earlier quoted context omitted.

> A person shows up eager to learn, expresses gratitude, feels scorned at all of the language-based gatekeeping that goes into this topic. They expressed gratitude for those who told them easy falsehoods and scorn for those who told them harder truths, characterizing such honesty as "gatekeeping". That's not the action of someone eager to learn, it's someone who's eager to avoid learning, like those politicians who,…

> scorn for those who told them harder truths Can you paste me in your post where you did this? (Note: you can't). I'll even paste your response, so you can remember better: >> 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…

You'll notice that the post you quote was a reply to their post, where, as I said:

> They said "It's like when the medieval Catholic Church refused to print a bible in anything but Latin so that they'd remain the sole authority on its content." and concluded with "shame on those who maintain this status quo."

And as I said before that:

> someone who comes in with guns blazing doesn't get to complain about being met with hostility

It's not "gatekeeping" when there's no effort to engage productively in the first place.

Re: Monads are monoids in the category of endofunctors

#156

Post by dataflow »

lmm wrote: post #98
dataflow wrote: post #31

Earlier quoted context omitted.

Isn't it more like, no mutation ?

What's state without mutation? If something is immutable then you can't tell the difference between a value and a copy of that value, so the question of whether it's "state" is rather meaningless.

I think you can define it. You just need to be willing to pin down some definitions so there's something you can formally talk about.

For example, let's say an "program" (in whatever abstract sense, whether you want to represent it as DAGs of function compositions or as a sequence of instructions or whatever else) takes, by definition, an infinite sequence of input symbols, and produces an infinite sequence of output symbols. Both sequences start (WLOG) at index 0. Note that for finite sequences, you can represent them by appending an infinite number of symbols that you consider null.

Let's say that "running" the program "until step k" (in whatever abstract sense you want to define, whether it's evaluating functions or following a sequence of operations or whatever) corresponds to "producing all outputs up to index k, aside from the information needed to represent the program itself.

As long as you formally define a way to measure information and a way to represent your program, I think you should be able to come up with a definition as I did above to define "program state" formally. You just need to be willing to do that, is all.

Re: Monads are monoids in the category of endofunctors

#157

Post by lmm »

dataflow wrote: post #156
lmm wrote: post #98

Earlier quoted context omitted.

What's state without mutation? If something is immutable then you can't tell the difference between a value and a copy of that value, so the question of whether it's "state" is rather meaningless.

I think you can define it. You just need to be willing to pin down some definitions so there's something you can formally talk about. For example, let's say an "program" (in whatever abstract sense, whether you want to represent it as DAGs of function compositions or as a sequence of instructions or whatever else) takes, by definition, an infinite sequence of input symbols, and produces an infinite sequence of output…

I don't think that captures the aspects people care about most of the "program state" that people care about is unrelated to I/O - particularly in Haskell, people care about programs that are essentially "evaluate this large equation" where there's only one piece of output at the end, but might be a lot of intermediate computation. And the details of what's stored in memory aren't what matters - after all, Haskell very deliberately makes no distinction between a plain value like 3 and a large and complicated thunk that will eventually evaluate to that value - but if you just measure the minimum number of bits required to store something equivalent then you've assumed away the whole evaluation of the program.

At least from the functional perspective you're coming at this from the wrong end in the first place - you're looking at it operationally rather than denotationally. The point of saying that there's "no state" or "no mutation" in a functional program is that there is no such concept at the semantic, code level: when reading any given piece of code, you don't need to think about state to understand what it's doing.

Re: Monads are monoids in the category of endofunctors

#158

Post by void_mint »

lmm wrote: post #155
void_mint wrote: post #125

Earlier quoted context omitted.

> scorn for those who told them harder truths Can you paste me in your post where you did this? (Note: you can't). I'll even paste your response, so you can remember better: >> 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…

You'll notice that the post you quote was a reply to their post, where, as I said: > They said "It's like when the medieval Catholic Church refused to print a bible in anything but Latin so that they'd remain the sole authority on its content." and concluded with "shame on those who maintain this status quo." And as I said before that: > someone who comes in with guns blazing doesn't get to complain about being met w…

Ah, so, the answer to my question:

> Can you paste me in your post where you did this?

Is "No but..."

So we're just saying things for the sake of it now, I guess.

Re: Monads are monoids in the category of endofunctors

#159

Post by lmm »

void_mint wrote: post #158
lmm wrote: post #155

Earlier quoted context omitted.

You'll notice that the post you quote was a reply to their post, where, as I said: > They said "It's like when the medieval Catholic Church refused to print a bible in anything but Latin so that they'd remain the sole authority on its content." and concluded with "shame on those who maintain this status quo." And as I said before that: > someone who comes in with guns blazing doesn't get to complain about being met w…

Ah, so, the answer to my question: > Can you paste me in your post where you did this? Is "No but..." So we're just saying things for the sake of it now, I guess.

> Is "No but..."

I don't care to show you where I did something I never claimed to have done in the first place.

> So we're just saying things for the sake of it now, I guess.

As far as I can tell that's what you've been doing the whole time. It's the height of hypocrisy for you to complain that "the purpose of your post clearly wasn't to help, provide value, enable, but instead to disparage."

Re: Monads are monoids in the category of endofunctors

#160

Post by void_mint »

lmm wrote: post #159
void_mint wrote: post #158

Earlier quoted context omitted.

Ah, so, the answer to my question: > Can you paste me in your post where you did this? Is "No but..." So we're just saying things for the sake of it now, I guess.

> Is "No but..." I don't care to show you where I did something I never claimed to have done in the first place. > So we're just saying things for the sake of it now, I guess. As far as I can tell that's what you've been doing the whole time. It's the height of hypocrisy for you to complain that "the purpose of your post clearly wasn't to help, provide value, enable, but instead to disparage."

:)
Post reply on HN