Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

a covariant comment is unclear, page 84 #118

Open
phderome opened this issue Jan 13, 2018 · 2 comments
Open

a covariant comment is unclear, page 84 #118

phderome opened this issue Jan 13, 2018 · 2 comments

Comments

@phderome
Copy link
Contributor

phderome commented Jan 13, 2018

“Equivalently we could say that B is a subtype of A if there exists a function A => B.”

I don't buy that one and it makes me confused. Say B is a car and A is a vehicle, B is subtype of A but I don't know of functions from vehicles to cars, in particular from a AB-320 or BA-747 to a car. Also the existence of a function between A and B is not relevant to A and B being subtypes of each other but that function is only relevant in the context of relationship of types F[A] and F[B].

What follows in the same section 3.6 reads fine to me but not that specific sentence.

See also Cats' contravariant.md for a discussion (which also is unclear with A <: B meaning A subtype of B or A having fewer instances than B and yet the code above it has B extending A): Subtyping relationships are "lifted backwards" by contravariant functors, such that if F is a lawful contravariant functor and A <: B then F[B] <: F[A], which is expressed by Contravariant.narrow.

Sam Halliday explains better contravariant, covariant, and invariant in FP for mortals, showing that covariant and contravariant extend invariant (see https://leanpub.com/fpmortals/read#leanpub-auto-variance and the nice picture with trait hierarchy where a lower node extends a node depicted higher); he also explains that a 'covariant functor' is just a regular functor as per common usage.

This chapter does make clear that we could use the term "Functor" for 3 type classes, but much much too late (explain this much sooner to avoid confusing the reader): contravariant, covariant, and invariant with covariant being the classical common usage people know (applicative and monad) and that effectively "functor" is sometimes taken to mean "covariant" but at other times the collection of the 3 type classes.

@phderome
Copy link
Contributor Author

by the way the imap example for Symbol and String was a true inspiration.

@phderome
Copy link
Contributor Author

See potential related PR regarding Cats' documentation: typelevel/cats#2154 on which @tpolecat had provided commentary in gitter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant