jethrolarson
commented
2 years ago Thanks for sharing!
It should explain map somewhere before it is used.
I keep going back and forth on this. Like is this fundamentally a glossary or something you read straight through? Also I fear there are some concepts which I think would prevent a sensical order. There is also the fact that changes to this document come from many people so maintaining a coherent flow hasn't happened.
Since it peaked on HN1 a few hours ago, there were some suggestions on things we could improve:
From mjburgess:
These definitions don't really give you the idea, rather often just code examples.. "The ideas", in my view:
Monoid = units that can be joined together
Functor = context for running a single-input function
Applicative = context for multi-input functions
Monad = context for sequence-dependent operations
Lifting = converting from one context to another
Sum type = something is either A or B or C..
Product type = a record = something is both A and B and C
Partial application = defaulting an argument to a function
Currying = passing some arguments later = rephrasing a function to return a functions of n-1 arguments when given 1, st. the final function will compute the desired result
EDIT: Context = compiler information that changes how the program will be interpreted (, executed, compiled,...)
Eg., context = run in the future, run across a list, redirect the i/o, ...
From ncmncm:
It should explain map somewhere before it is used.
For the more abstruse and abstract concepts, a comment suggesting why anybody should care about this idea at all would be helpful. E.g., "A is just a name for what [familiar things] X, Y, and Z have in common."
It goes off the rails halfway through. E.g. Lift.
From sanderjd: Expanding on your #1, I think they could use some more definitions. As you say, they use "map" in its functional programming sense before defining it, but I think more confusing is this one:
What is a "morphism"?
I think this is a great starting point though, which could use some expansion.