I don't agree that a transformation which takes an int[] and outputs a string[] is an endofunctor. Yes they are both arrays, but they are different types.
Monads are monoids in the category of endofunctors
171–180 of 241 posts
Re: Monads are monoids in the category of endofunctors
#172Earlier quoted context omitted.
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.
Yes, that goes for teachers. Not normal working programmers who choose to discuss FP in the terminology which has been commonplace for decades. They are under no such obligation.
Re: Monads are monoids in the category of endofunctors
#173Earlier quoted context omitted.
> a monad is a type constructor Now explain what a "type constructor" is, otherwise these words are worthless.
Here's how I like to think about things: Values are things . Concrete. Since we are manipulating computers, a value is really just some abstract symbols--1s and 0s occupying a slot in memory. The meaning of the symbols exists on a higher level, what we usually call semantics . Types are a well-studied method to attach semantics to blocks of otherwise meaningless (but concrete!) symbols. By declaring a variable (which…
Nice explanation! Minor nit toward the end:
> So a monoid is also a type constructor
Is it? You claimed correctly a couple paragraphs back that a functor is a type constructor F bundled with the ability to "lift" functions into the context of F. So `List` is a functor in the usual way, and so on. But a monoid cannot be a type constructor, or else `String` could not be a monoid. A monoid is a concrete type M bundled with multiplication and unit on that type.
Re: Monads are monoids in the category of endofunctors
#174Earlier quoted context omitted.
> a monad is a type constructor Now explain what a "type constructor" is, otherwise these words are worthless.
Here's how I like to think about things: Values are things . Concrete. Since we are manipulating computers, a value is really just some abstract symbols--1s and 0s occupying a slot in memory. The meaning of the symbols exists on a higher level, what we usually call semantics . Types are a well-studied method to attach semantics to blocks of otherwise meaningless (but concrete!) symbols. By declaring a variable (which…
That was a really nice description. I've struggled to get traction with a lot of this stuff for a while (and not really needed to understand it, so my curiosity remained unstated) ... but this has really helped. Thank you!
Re: Monads are monoids in the category of endofunctors
#175For those who wonder, you don't need to know about category theory to use monads as a programmers.
[deleted]
Re: Monads are monoids in the category of endofunctors
#176Earlier quoted context omitted.
You can't do that in idiomatic JavaScript, at least I've never done such a thing in the past 15 years. Maybe you could share an example to show me?
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.
Re: Monads are monoids in the category of endofunctors
#177I don't agree that a transformation which takes an int[] and outputs a string[] is an endofunctor. Yes they are both arrays, but they are different types.
It depends on the category. You can have a category of arrays of ints, but you can also have a category of arrays.
Re: Monads are monoids in the category of endofunctors
#178Functional programming is subject to an enormous amount of gatekeeping. Kudos to the author for pushing that gate wide open.
Agree. Too often descriptions of monads assume that the reader has no formal math training whatsoever and do a lot of handwaving, diagrams, examples, etc. without actually providing a useful definition. This post is the exact opposite.
Yes, it's also opposite in terms of its correctness.
Re: Monads are monoids in the category of endofunctors
#179Earlier quoted context omitted.
What makes a type constructor a functor, what's the difference
I might get flack from the FP purist crowd, but I like to think of functors as containers + context. - 5 is a value. Its type is int - int is a type - T is a type parameter. Like the x in "f(x)", we have to pass one in to evaluate it - List is a type constructor. It takes a type, T, and spits out a new, "compound" type. It will "contain" T's. - [3,5,7] is a list. Its type is List . We fed the type "int" to List to co…
I have pretty much the same intuition, except I think of functors not just as containers, but as sources of T. If you have a source of Ts, you can adapt it with a function from T to S to get a source of Ss. If you want to apply a pipeline of type-changing operations to some source of initially Ts, a functor is the right metaphor. (And if you have a sink instead of a source, that's a contrafunctor.)
If you have two sources and you want to combine them into a single source, you need an Applicative Functor, also known as a monoidal functor.
If you have a source that itself produces sources, and you want to flatten the nesting and treat it as a single-level source, you need a Monad.
> F -> () (a function which takes a T and returns nothing) is a type constructor. It's not really a functor.
I'm having a little trouble matching the prose against the type signature. A function which takes a T and returns nothing would have type `T -> ()`; no F in sight. I'm guessing you meant that F is defined to give `T -> ()`, in which case F is indeed not a functor; it's a contrafunctor, a place to which Ts can be sent (not retrieved).
Re: Monads are monoids in the category of endofunctors
#180Earlier 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…
> 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.
This sentence just taught me more about functional programming terminology than 4 years of university and 20 years of casual blog-post reading :O