Avoid confusing different meanings of the same word, eg Functor

[PaulBone]

Even within FP there are multiple meanings of some terms, a good example is functor. You've covered one meaning and might not be aware of the other two meanings.

1. In OCaml a functor is part of the parametric module system. I think that it means parametric module but I'm not certain, and I don't feel confident writing this section myself. https://realworldocaml.org/v1/en/html/functors.html
2. In languages using DU types (Haskell, Mercury etc), Functor is another word for constructor.

[jethrolarson]

I think defining all meanings will be more confusing to newcomers. For academic descriptions of these concepts there are other better sources.

[PaulBone]

That makes some sense, however a person starting FP for the first time might hear a term used to mean one of the other meanings, if they check this glossary it could lead them to the wrong conclusion. This can be worse than having no glossary at all.

Another approach may be to qualify the definitions with multiple meanings. Again with functor as an example, you could say "Functor has several meanings, in the context of Haskell functor usually means...".

On reddit several people said that this appears to have a focus on Javascript. Perhaps all the definitions are intended to be in the context of Javascript and that I didn't understand that when I read this.

[jethrolarson]

Yeah all the examples are in JavaScript. It's not the best language for
describing these concepts but it's the best language for reaching curious
developers

On Mon, Jul 25, 2016, 7:53 PM Paul Bone [email protected] wrote:

That makes some sense, however a person starting FP for the first time
might hear a term used to mean one of the other meanings, if they check
this glossary it could lead them to the wrong conclusion. This can be worse
than having no glossary at all.

Another approach may be to qualify the definitions with multiple meanings.
Again with functor as an example, you could say "Functor has several
meanings, in the context of Haskell functor usually means...".

On reddit several people said that this appears to have a focus on
Javascript. Perhaps all the definitions are intended to be in the context
of Javascript and that I didn't understand that when I read this.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#62 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB-4DHgQ9XuAgpxwTGBUjc5r3I_gkcBks5qZXabgaJpZM4JTrs9
.

[PaulBone]

That's a good choice, I'm sure this will be a good resource for many. Although maybe something about the intended scope/context should be placed at the top of the file?

[jethrolarson]

Yeah the intro needs work

On Mon, Jul 25, 2016, 8:11 PM Paul Bone [email protected] wrote:

That's a good choice, I'm sure this will be a good resource for many.
Although maybe something about the intended scope/context should be placed
at the top of the file?

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#62 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB-4DcbdvpG4CXwspW91poewPC0dQxSks5qZXrUgaJpZM4JTrs9
.

[hemanth]

Defining them in simple terms is the challenge? 🤔

[gsklee]

It was indeed very confusing because the mathematical definition of functor actually means the transforming/mapping function, not the container object/category. But then I saw the explanation at the very beginning of the document which said all term definitions follow Fantasy Land Spec, so I guess that's it.

[jethrolarson]

This doc covers more topics than the fantasyland spec but it's using the
names and definitions as described there where applicable.

On Tue, Jul 26, 2016, 1:21 AM G. Kay Lee [email protected] wrote:

It was indeed very confusing because the mathematical definition of
functor actually means the transforming/mapping function, not the container
object/category. But then I saw the explanation at the very beginning of
the document which said all term definitions follows Fantasy Land Spec, so
I guess that's it.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#62 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB-4M8IQuXE6N1sQMe8H6NkEoZm19PAks5qZcNygaJpZM4JTrs9
.

[jethrolarson]

I've been thinkin about this a bit. Maybe it is worthwhile to go into a little more detail on functor. Especially since map is endofunctor. We can then group the other morphisms under it

[jethrolarson]

Monad can go under there too ;)

[sebinsua]

It would be sensible to at least acknowledge that somebody might read text that gives a word a different meaning by pointing out at the bottom of words that have multiple common definitions that the definition discussed is the FantasyLand spec one. You could even link to resources that could describe the other usages.

Otherwise a beginner will read one of these words, and then go and check these docs and they could end up more confused than they would have been if otherwise.

[jethrolarson]

I've been considering reworking the functor section and grouping the
various functors under it (applicative, monad, endofunctor, etc).

On Thu, Jul 28, 2016, 4:44 AM Seb Insua [email protected] wrote:

It would be sensible to at least acknowledge that somebody might read
content that gives the word with a different meaning with a sentence
pointing out that there are non-FantasyLand spec definitions when they are
at all common.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#62 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB-4GVNr-JLRvwxtyFUbrBVE5SAdHZ_ks5qaJYRgaJpZM4JTrs9
.

[sjsyrek]

It's worth remembering that this document is about FP, not math or category theory, and a functor in FP is a mappable structure. That definition is universal in programming so far as I can tell even if it has slightly different meanings in other contexts. Actually, it is my understanding that in CT you don't really separate the arrow from the objects it points to/from, so a functor represents a kind of relationship (or transformation) for a species of object without regard for its structure otherwise. So the functor as type class, which captures the transformation while abstracting the structure, is a pretty decent approximation, and an approximation is all it will ever be outside the world of Platonic forms. I've read functor described as a "function object" that simply generalizes how the arrow or () operator is overloaded for a given data type, and I had been thinking about writing something up along those lines. But if this document is for beginners, and for programmers, does it make sense to muddy the waters by suggesting a functor isn't always a thing you can map over? Anyone who wants to dig deeper can always follow provided references or else do their own research. In the meantime, [].map is probably the most important beachhead we have.

[sjsyrek]

Sorry, I realize I may be overly influenced by Haskell here, given what was pointed out about OCaml above. Still, everywhere else I've seen functors they have been more like the Haskell idea—using collections as a starting point. The OCaml idea still seems roughly the same sort of thing, though: overloading the morphism arrow within a given category. Now that I think of it, most languages that have them probably ditch the terminology. Like Swift. Rust, too. I guess the point of even using them here is to familiarize people with terms they may encounter or patterns they definitely will encounter and that are important to FP. Endofunctor may send them screaming for the hills, though most functors in programming contexts are endofunctors anyway. Names are so hard in CS and it's 7 am here so I give up for now.

[PaulBone]

@sjsyrek That is exactly the problem with only acknowledging a single definition for overloaded terms. It's easy to be influenced by the use of this term in Haskell and that can lead you to make an incorrect assumption outside of that context. I'm not saying that every meaning should be defined but acknowledged maybe with a link is good enough.

[sjsyrek]

Indeed, it's equally tricky given the JS-orientation of this document since JS has no definition for things like functor. But how many other contexts define functor differently than "a structure to be mapped over" which is essentially overloading function application for a particular kind of thing (I hesitate to say object)? i.e. "objects" plus morphisms? I find myself in this weird position of trying to avoid semantic arguments and basically now creating one. So, I guess another problem would be trying to cover all possible contexts if there really are other contexts we ought to consider. By covering more than one, do we risk presenting a partially complete set as if it were a complete set? Or do we risk alienating newbies by putting disclaimers everywhere that our definitions are correct in these contexts, but not those, and by the way there may be more we don't mention or know about.

@PaulBone hey I loved you on Functional Geekery! Made me almost not want to give up entirely on Mercury-like languages (Agda?)

[PaulBone]

Just acknowledge the ones you know about, I'm sure other pedants like me will point out when you've missed one ;-)

I'm glad you enjoyed it. In the next few weeks I'll add my other talks and things to my website. I have a new talk coming up at the end of August too.

[sjsyrek]

Hey maybe we need to add a podcasts section. Between Functional Geekery, the Haskell Cast, and the the new LambdaCast, there's plenty of material. Plus individual episodes of JS podcasts that cover FP in that world.

[jethrolarson]

@sjsyrek I like your intuition here. This really is a document for beginners, programmers, and JS programmers at that. Our goal should be to keep people reading without getting a mental stack overflow. A simple caveat like "This differs from [functors in mathematics]" where then we can link off to an article or wiki could be enough