> this array stops being a functor? An individual array, as a runtime object, isn't, never was, and never will be a functor, as the term is used in this discus

> this array stops being a functor? An individual array, as a runtime object, isn't, never was, and never will be a functor, as the term is used in this discussion. Rather, the functor is the type constructor of arrays itself (to be pedantic: the type constructor and the `map` function). In the grammar of most programming languages, type-level and value-level terms are kept separate, so not even in principle could you conflate a type constructor (a type-level entity) with a runtime object (a value-level entity). <rant> This is a very common problem. Most programmers are only used to reasoning about runtime objects, like “lists”, “sockets” and “windows”. Inasmuch as they talk about entities that don't have a runtime manifestation, like “types”, “preconditions” and “invariants”, these words are merely used as shorthand for things they want to say about runtime objects. Understanding how concepts from abstract algebra and category theory are applied to programming requires a change of mindset: the subject matter is no longer “what happens to this individual object”, but rather “what is the structure common to a large class of objects” and “how can this structure be used as the backbone of our algorithms”. This requires a new vocabulary in which abstract structures (which describe or constrain the representation of runtime objects, but don't have a runtime representation of their own) are first-class entities, so that you can say “the type constructor of immutable arrays is a functor” just as easily as you can already say “this runtime object is an array”. </rant>