A much better example would be "Show"(Showable) vs "Traversable".
A much better example would be "Show"(Showable) vs "Traversable".
If you really want to mess things up, use names that mean something different every day.
But I would know what a “Mappable” should be, regardless of PL.
No, it has the same meaning. It does not behave identically because the languages do not have identical designs.
>But I would know what a “Mappable” should be, regardless of PL.
Lots of people wouldn't, and would be wondering what cartography has to do with anything. And even for people familiar with the functional "map", now they would just have an incorrect idea of what Functor is. Lots of Functors are things most people would not think of as being "Mappable".
> No, it has the same meaning. It does not behave identically because the languages do not have identical designs.
Functors in Haskell and OCaml are different things. Haskell Functors correspond to the category-theoretic notion of a functor (a thing mapping objects to objects and morphisms to morphisms in a reasonable manner). In OCaml and ML, Functors represent parameterized modules. These are not known to correspond to category-theoretic functors in any reasonable way (and there have been proposals for category-theoretic models of the ML module system). I guess the term Functor is a bit of a misnomer in the ML-like languages.
No, functors represent functions from a module to a module. Oh hey, that sounds just like the standard definition of a functor. As I said, the behavior is different because the languages are different, but both are named after the category theory functor, because they both emulate it.
http://cs.stackexchange.com/questions/9769/what-is-the-relat...
Functors play very different roles in Haskell and OCaml/ML.
In Haskell, the Functor class is there to implement the functoriality of a type. If F is a functor, then one implements maps of type F A -> F B from given A -> B in a functorial way.
In ML, the term functor was chosen because they are not first-class functions, but "a level up" (much like a functor is a level up from the maps in the category that it operates on). However, if F is an ML functor, then there are no "maps" between the modules F(A) and F(B). The morphism part, which is the essence of a Functor in Haskell, is missing in ML. This is why I think that the functor terminology isn't very good in ML.
Not everything that maps one thing to another is a functor.
Yes there is, the functor. Just repeating a false statement won't make it come true.
What we have is a functor F, which would be defined as in:
module F =
functor (X: S) -> ....
If you have two modules A and B of signature S, then you can form F(A) and F(B) and these are both modules. Now where are the maps from F(A) to F(B)? Just saying "the functor" does not explain this.> Just repeating a false statement won't make it come true.
Exactly!
If you want to claim a relation between OCaml functors and category-theoretic functors, then you must be able to justify your claims. Saying "functors represent functions from a module to a module. Oh hey, that sounds just like the standard definition of a functor." is just not a convincing argument.
That is literally the functor. Seriously, read the chapter on modules.
That would be an answer for Haskell (though a proper one would refer to fmap), but it does not work like that in OCaml. You do know some OCaml, right?
But if it's so obvious, then you can say how it works for the following concrete example:
module type S = sig
type t
val f: t -> int
end
module F = functor (X: S) -> struct
type s = X.t * X.t
let g x = X.f x + X.f x
end
module A : S = struct
type t = float
let f x = int_of_float x
end
module B : S = struct
type t = int
let f x = 2*x
end
module X = F(A)
module Y = F(B)
How do I get from X to Y by "literally the functor"?The point is: In the ML module system there is no equivalent to fmap: (A -> B) -> (F A -> F B), i.e. the functor action on morphisms. So, functors in Haskell and OCaml are different things. If you want to claim otherwise, you'll have to make an actual argument for it.
NB You only need to get from X to Y in ways that arise from getting from A to B. Since there doesn't seem to be any relevant concept of morphism it's hard to see how ML functors are anything other than trivially category theoretical.
Lots of terms like Profunctor, Contravariant Functor, Bifunctor etc. (which are also the names of typecasses in Haskell) rely on the precise, category-theoretical definition of Functor.