Earlier quoted context omitted.
Not every type constructor is a functor.
What makes a type constructor a functor, what's the difference
in OO langauage:
Collection is a class, but not every class is Collection.
Monads are monoids in the category of endofunctors
81–90 of 241 posts
Re: Monads are monoids in the category of endofunctors
#82Wait, 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 -…
You see, there's a bit of irony here in characterizing jargon as gatekeeping, because in the author's attempt to distill it, some pretty critical stuff got lost in translation.
I share the sentiment that FP jargon can be impenetrable to the uninitiated, but the same can be said about programming jargon to non-techies: it may sound like gatekeeping to talk about "closures" but there's technical reasons why closures are called closures and global state being accessed by functions are not.
The same goes for FP. Saying `val => val + val` is a functor because it maps numbers to numbers isn't really correct: you could arguably only say that in an universe where `val + val` is the only possible operation, and even then, that's not really correct because the utility of the function is hardcoded (meaning that if we were to hypothetically introduce an axiomatic operation, the internal consistence of this new algebra would implode). In a more useful algebra in a regular universe, the mapping must hold for any valid operation for that type. So a functor for the `number` type ought to look more like something like `Number.prototype.map = function(f) {return f(this)}` (i.e. the mapping contract holds for addition, subtraction, and all other algebraic operations that are valid on numbers contained within `f`)
There are also practical technical things the article glossed over: Array.prototype.map is not monadic. The signature of the callback is `(T, number, Array) => U`, which is most certainly not unary (and for that matter, using JS to illustrate FP is fundamentally problematic since JS isn't side-effect-free to begin with). If you think that's nitpicky, one fundamental thing with FP is that composition relies heavily on algebras not breaking on corner cases. This is why, for example, fantasy-land specifies a different method name for `map` (called `fantasy-land/map`); because `map` is already taken by Array and it breaks some composition patterns (notoriously, `[1,2,3].map(parseInt)`)
Re: Monads are monoids in the category of endofunctors
#83Earlier quoted context omitted.
I’m helping the dude improve his writing with a short and minimally critical comment. Hall monitor elsewhere.
How can you tell that he's well dressed or lives in a city? https://en.m.wikipedia.org/wiki/Dude
I… what? Is your position then that we should have this discussion using pre-computing word definitions only?
Edit: Oh I see the joke now.
Re: Monads are monoids in the category of endofunctors
#84Wait, 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 -…
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…
So monad is used to construct a new Type dynamically instead of writing it? And functor is also the same?
Re: Monads are monoids in the category of endofunctors
#85Earlier 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.
You asked. I'm happy to dissect it to your level, but I don't know what you may be familiar with, and if you're not comfortable with type functions, I'm going to have a hard time motivating the extra bits a functor has.
The List functor is a combination of the type function sending `T` to `List` and the ... what do you want me to call it, a function function? implemented in Java as:
static Function, List> map(Function f) {
return (ts) -> {
var ss = new ArrayList();
for (final var t : ts) ss.add(f.apply(t));
return ss;
};
}
But it's not the `map` method that's the important part, so much as the idea that we can (or want to; can't in Java) pass `List` to any function that needs a Functor, which can then use whatever `map` implementation that functor has, without knowing what actual type function it was given.
Really, I suspect it's neither the type constructor nor the map function that's the conceptual hurdle. It's abstracting over the type constructor; taking a type constructor as a parameter. You may have never used a language that supports that, or seen a need for it, and this may all seem like needless sophistry until you do.
Re: Monads are monoids in the category of endofunctors
#86Wait, 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
That's only Haskell. The other FP languages have sane communities.
Re: Monads are monoids in the category of endofunctors
#87Earlier quoted context omitted.
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 t…
As another commenter pointed out, the key is to use an example as a starting point and then refine from there. "X is like Y, but different in these ways". Comparisons don't muddy the waters; they give people a quantum-leap from 0% understanding to 70% or 90% understanding, from which point the remaining gap can be filled in at the usual rate. To ignore this is to ignore human nature.
Re: Monads are monoids in the category of endofunctors
#88Earlier 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…
I don't like creative explanations. Definitions are easier. A functor is a PAIR, please notice the emphasis, of a type constructor F and a map function with the following signature: a -> b -> f a -> f b. Its not a type constructor, it's a pair of two things, the type constructor AND its map function. Now that we said what it is we provide the usual simple example of Array, Record or Option, show the type constructors…
> `a -> b -> f a -> f b`
(a -> b) -> F a -> F b; the parentheses are critical. I don't fully disagree with your point, but if you're going to emphasize rigor and definitions, it would be wise to make sure you're not setting people on the fence up for mistakes akin to those in the original post.
(You also called it `F` and then used it as `f`.)
Re: Monads are monoids in the category of endofunctors
#89Earlier quoted context omitted.
1. no state 2. no side effects And you get most of the benefit of FP in a way that everyone can understand and can use any language.
Isn't it more like, no mutation ?
Not exactly. When using the I/O monad in a pure language like Haskell, your code doesn't directly have side effects, instead you're building a container (a monad) of instructions of what side effect having operations to do, and what should be done with the results. The Haskell runtime then takes this monad and unwraps it layer by layer, each layer executing the side effect having instruction and using the results of the side effects as input for unwrapping the next layer.
You could argue that because of this system the language itself is pure and without side effects and without mutation.
Note that the effect of this system is exactly the same as a language that does have side effects. They are functionally identical. The nicety of Haskell's purity comes from how the monads allow you to organize your code.
By the way, not sure if this is controversial but JavaScript's I/O system is a lot like the I/O monad. I/O doesn't really get executed immediately, and you can't directly operate on the results of I/O. The runtime executes the I/O after all JavaScript's been executed, and you use callbacks to tell the runtime to do whenever the I/O data returns.
Of course JavaScript does allow for mutation, so it's not pure in that sense.
Re: Monads are monoids in the category of endofunctors
#90Earlier quoted context omitted.
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"…
I actually agree with this much. Explaining monads before explaining a lot of concrete examples of monads is putting the cart before the horse, and is where a lot of these tutorials go wrong (https://m50d.github.io/2013/01/16/generic-contexts is my own effort at taking the opposite approach). But calling something a functor when it isn't is extremely unhelpful; the whole point of using a special-purpose term like functor is to be very precise about what it is and isn't, and to avoid intuitions that would be misleading.