adds contravariant functor to spec #150

rjmk · 2016-08-21T17:06:49Z

Resolves #149

scott-christopher · 2016-08-22T00:49:15Z

README.md

@@ -380,7 +402,7 @@ method takes two arguments:
 ### Profunctor

 A value that implements the Profunctor specification must also implement
-the Functor specification.
+the Functor and Contravariant Functor specifications.


I'm in two minds about including this here.

In some other typed languages we'd have an issue where the variance of the type arguments of contravariant and profunctors don't line up. We don't have this issue with a regular covariant functor and profunctor because both last type arguments are covariant (we just have to partially apply the type constructor to take the kind of profunctor from * -> * -> * to * -> *).

The other half of my mind says this is probably being pedantic as we're not bound by such a type system so it's not really a problem.

Hmm.

Am I right in thinking that there could be a class AmateurFunctor with the opposite problem?

class AmateurFunctor f where amateurmap :: (a -> b) -> (c -> d) -> f a d -> f b c

I'm slightly unclear if there's a connection between the variance of the type arguments in the kind and the variance of type parameters in the type.

Am I write in thinking that there could be a class AmateurFunctor with the opposite problem?

In something like Haskell, a type that implements AmateurFunctor could only be declared as Contravariant.

class AmateurFunctor f where amateurmap :: (a -> b) -> (c -> d) -> f a d -> f b c class Contravariant f where contramap :: (b -> a) -> f a -> f b instance AmateurFunctor f => Contravariant (f a) where contramap = amateurmap id

To also declare it as a Functor you would need to flip the order of the type arguments with a newtype.

newtype Flip f b a = Flip { unFlip :: f a b } instance AmateurFunctor f => Functor (Flip f a) where fmap f = Flip . amateurmap f id . unFlip

If however we were to ignore the notion of type arguments, it could just be stated that:

p.promap(f, g) = p.contramap(f).map(g) = p.map(g).contramap(f)

It looks a little odd for me to see contramap and map being applied directly to the same type, but as the Flip newtype above highlights, the types are effectively identical.

Am I right in thinking that there could be a class AmateurFunctor with the opposite problem?

In something like Haskell, a type that implements AmateurFunctor could only be declared as Contravariant.

Yup, that's the sort of thing I was thinking.

I think I get it now. It's for the same reason that the functor for a tuple is on the second element and for a function is on the codomain?

One thing I'm slightly confused about is the variance of type arguments. I think that in a value level function f :: a -> b -> c, both of the first two params are in negative position. Is that different for a kind T :: * -> * -> *? Or am I misapplying reasoning in an inappropriate domain?

I don't think it's that straight forward. Take Flip f a b. How these variables are used depends on f. If you have

newtype Reader a b = Reader (a -> b) newtype Op a b = Op (b -> a)

Then, Flip Reader a b has the a and b in positive and negative position, respectively.
But, Flip Op a b has the a and b in negative and positive position, respectively.
All while Flips kind is still * -> * -> *.

There may be some relationship though.

I see! I think. Here's a statement my understanding would predict to be true: there's a Contravariant instance for Op, but no Functor. Is that correct?

I'm still not quite sure I get

In some other typed languages we'd have an issue where the variance of the type arguments of contravariant and profunctors don't line up

In that I think I see the problem now, but I'm not sure I see it's relation to variance of the type arguments

Also there seems to me to be an inessential semantic issue at hand. In that one speaks of, say, the functor instance for functions, but it's seems somewhat conventional / tied to Haskell's syntax that we say fixing the first type variable gives us 'the' functor instance. Might it not be more accurate to talk of the functor instance for functions of fixed domain?

It may be that I have a fairly deep misunderstanding that would take a lot of teaching effort to resolve, so will happily accept being told to go and read something etc.

Here's a statement my understanding would predict to be true: there's a Contravariant instance for Op, but no Functor. Is that correct?

Yep!

Might it not be more accurate to talk of the functor instance for functions of fixed domain?

Probably 😉.

I'll let @scott-christopher respond to your other questions, as the lack of type variables is confusing me.

Thanks, @joneshf.

I think I am also pro removing it as a dependency. Are you happy for me to push up the removal, @scott-christopher?

rpominov · 2016-08-22T17:17:35Z

Do we want to add promap derivation via map and contramap to Derivations? Or do you conclude that this is a bad idea to connect promap and contramap (the discussion above went way over my head)?

rpominov · 2016-08-22T17:23:10Z

Btw, derivations also act as restrictions (additionally to laws):

If a data type provides a method which could be derived, its behaviour must be equivalent to that of the derivation (or derivations).

Maybe that adds something to the discussion :)

rjmk · 2016-08-22T17:35:24Z

@rpominov The issue is that a type P a b, if there's a profunctor instance for P has a (covariant) functor instance for P a, but a contravariant functor instance for P _ b (which is not a valid expression). So then in fact the derivation could not be achieved

(If we were to allow the 'partial application' in the type to be in the middle as well as the end, then we would not know whether the contrafunctor instance for P a b was on the a or the b so we wouldn't be able to have a reliable derivation)

rpominov · 2016-08-22T17:51:47Z

Ah, I see. So the problem is that Haskell's higher kinded types don't allow this because it doesn't support P _ b syntax. But this problem exist only in Haskel, right? And also everything is still correct semantically, the problem is only with syntax.

Do we need to care about this in a specification that targets JavaScript?

rjmk · 2016-08-22T18:21:42Z

I'm not sure it's only syntax (I am far from an expert); I worry that we introduce a possibility for unlawfulness with that degree of freedom

El 22/08/2016, a las 18:51, Roman Pominov notifications@github.com escribió:

Ah, I see. So the problem is that Haskell's higher kinded types don't allow this because it doesn't support P _ b syntax. But this problem exist only in Haskel, right? And also everything is still correct semantically, the problem is only with syntax.

Do we need to care about this in a specification that targets JavaScript?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

rjmk · 2016-09-01T15:18:20Z

Some more thoughts on this

Pro

As it stands, there's nothing to stop someone defining Semigroup b => instance Monad Either _ b, for Fantasy Land (please excuse the notation)

Con

Part of the purpose of this repo is to help people port knowledge from languages with ADTs
- Demanding a contravariant instance for a profunctor would be very confusing for them
We're confident that the way it is in Haskell fits together sensibly. I, at least, am not sure I want to gamble that nothing goes wrong when you stop considering type constructors as kind functions and partially applying them to get the various instances
Being a dependency to profunctor has little effect on if contravariant is useful

That said, I think let's drop the mention and maybe raise an issue to return to it?

SimonRichardson · 2016-09-05T21:40:58Z

Can you update to the latest master (you'll also need to add a type signature), then it's one step closer to merging.

Thanks.

* 'master' of github.com:fantasyland/fantasy-land: Add ChainRec specification (fantasyland#152) Add type signatures to spec (fantasyland#147)

rjmk · 2016-09-06T08:18:51Z

⚡

I also removed the dependency mention

SimonRichardson · 2016-09-06T11:12:44Z

@rjmk you need to update again sorry, more changes have just been dropped. 🎱

* 'master' of github.com:fantasyland/fantasy-land: change spec to require prefixed names (fantasyland#146)

rjmk · 2016-09-06T11:38:34Z

⚡

rpominov · 2016-09-28T18:13:25Z

Should this thing be called Cofunctor for consistency with Comonad?

rpominov · 2016-09-28T19:01:00Z

Probably not. Cofunctor is the same as Functor http://stackoverflow.com/questions/34732571/why-there-is-no-cofunctor-typeclass-in-haskell/34732721

rjmk · 2016-09-29T12:11:13Z

You may be interested to know that there is no contravariant (co)monad! Because if you tried to nest the instances of the monad, you'd have contra-contravariance, which is just covariance! So your join would be unlawful

Another way at looking at it is that the contravariance ruins the monoidality of the endofunctor ;)

rpominov · 2016-10-11T21:36:43Z

Lecture about Contravariant Functor from Category Theory course by Bartosz Milewski: https://youtu.be/wtIKd8AhJOc?t=26m46s .

It can be interesting for people who are still learning (like me). I like the analogy he makes that if Functor is a box, than Contravariant Functor is like an engine that needs a value of type a as fuel in order to run. Creates good intuition!

Also he talks a bit about the name (Cofunctor vs Contravariant Functor) and about connection between Contravariant Functor and Profunctor.

* 'master' of github.com:fantasyland/fantasy-land: (29 commits) Version 2.1.0 Add Alt, Plus and Alternative specs (fantasyland#197) Use uppercase letters for Type representatives in laws (fantasyland#196) Fix id_test and argument order in laws (fantasyland#193) Version 2.0.0 Another go at updating dependencies (fantasyland#192) release: integrate xyz (fantasyland#191) test: remove unnecessary lambdas (fantasyland#190) require static methods to be defined on type representatives (fantasyland#180) lint: integrate ESLint (fantasyland#189) Enforce parametricity (fantasyland#184) readme: tweak signatures to indicate that methods are not curried (fantasyland#183) Fix reduce signature to not use currying (fantasyland#182) Link to dependent specifications (fantasyland#178) Add Fluture to the list of implementations (fantasyland#175) laws/functor: fix composition (fantasyland#173) laws/monad: fix leftIdentity (fantasyland#171) Minor version bump bower: add bower.json (fantasyland#159) Fix chainRec signature to not use currying (fantasyland#167) ...

rjmk · 2016-11-12T13:27:04Z

How do people feel about this?

safareli · 2016-11-12T14:02:29Z

I thinkfigures/ should be updated too.

davidchambers · 2016-11-15T01:40:51Z

README.md

+#### `contramap` method
+
+```hs
+contramap :: Contravariant f => f a ~> (b -> a) -> f b


If Contravariant is the name of the type class, should we remove "Functor" from the heading?

Are there any examples of contra variance on value based ADTs?

I have only seen them on function based bits that have their returns fixed. I know it moves away from the Haskell definition, but would it make sense to adopt a signature more like:

Contravariant f => f a b ~> (c -> a) -> f c b

or

Contravariant f => f (a -> b) ~> (c -> a) -> f (c -> b)

Or is that too limiting for the spec?

EDIT: Not specific to your question @davidchambers just not very good at a github ;)

Or....does this just imply that the return is fixed and only specifies where the variance occurs?

In any case, it may make for an easier intuition for consumers determining if they indeed have some contra variance available to them

Sure, you can have something like.

data Foo a = Foo

And that can be contravariant:

instance Contravariant Foo where contramap _ _ = Foo

Interestingly, it's also covariant 😄

instance Functor Foo where fmap _ _ = Foo

Or if you're lazy:

{-# LANGUAGE DeriveFunctor #-} data Foo a = Foo deriving (Functor)

We shouldn't use the signatures above because they do limit the spec too much. For instance Foo couldn't be Contravariant with either of those signatures.

Perfect! Thanks @joneshf!! just the answer I was looking for!!

TIL!

To answer @davidchambers question: yes, I think we should rename this to Contravariant. Afterwhich, we should merge this.

@rjmk Are you up to this last change? If not, let me know and I'll make it and get this merged.

safareli · 2016-11-15T08:24:08Z

And height of img tag in readme should also be updated to 271

JeffDownie · 2016-12-05T22:38:19Z

Is it a good idea to hide the dependency of profunctor? A profunctor looks (at least to my eyes) a lot harder to understand than a contravariant functor anyway - if someone can figure out their object is a profunctor, they can figure out it's a contravariant functor.

Hiding the links between these structures really detracts from using fantasyland as a learning resource too.

rjmk · 2016-12-05T23:35:24Z

In Haskell, there is no dependency of Profunctor on Contravariant functor. Contravariant functors only have one 'free' type variable, whereas Profunctors have two. For any profunctor P, we can define data P' b a = P' (P a b) such that P' b is a contravariant functor (nb: not P'). Considering that we use Haskell syntax for the type signatures, I think we should probably stick to what they can express

JeffDownie · 2016-12-06T07:30:20Z

It just seems weird, though, limiting ourselves to what a different languages' type signature can represent.

Haskell doesn't seem like the perfect standard to hold this repo to (at least in this case, don't get me wrong, most of the time it's amazing :D). Saying something is or isn't a given mathematical structure based on the order of arguments in its' constructor just feels icky/wrong.

rjmk · 2016-12-06T09:53:28Z

I get that concern. However, considering the construction of the rest of the spec in terms of Haskell syntax, I don't think this PR is the appropriate place to diverge

JeffDownie · 2016-12-06T10:10:44Z

True - that sound excessive for this PR :D

davidchambers · 2016-12-19T21:05:16Z

README.md

@@ -4,7 +4,7 @@

 (aka "Algebraic JavaScript Specification")

-<img src="logo.png" width="200" height="200" />
+<img src="logo.png" width="200" height="271" />


Is this change intentional? Perhaps you meant to update the dimensions of figures/dependencies.png instead?

Oh dear! Yep, that's right

davidchambers · 2016-12-19T21:07:58Z

figures/dependencies.dot

@@ -13,6 +13,7 @@ digraph {
  Extend;
  Foldable;
  Functor;
+  "Contravariant Functor";


Should this match the name of the section heading? I would like to see both named Contravariant or ContravariantFunctor (I don't mind which).

davidchambers · 2016-12-20T15:54:12Z

figures/dependencies.dot

@@ -13,6 +13,7 @@ digraph {
  Extend;
  Foldable;
  Functor;
+  Contravariant;


figures/dependencies.png still shows "Contravariant Functor". ;)

Contravariant functor PR fixes

davidchambers · 2017-01-30T11:40:02Z

README.md

@@ -28,7 +29,7 @@ structures:
 * [Bifunctor](#bifunctor)
 * [Profunctor](#profunctor)

-<img src="figures/dependencies.png" width="888" height="340" />
+<img src="figures/dependencies.png" width="1068" height="347" />


Rather than the image's natural dimensions, I think we want the dimensions of the scaled image on GitHub:

<img src="figures/dependencies.png" width="888" height="289" />

Sorry, Didn't realize we were scaling things 😊.

Avaq · 2017-01-30T12:44:44Z

README.md

+       unspecified.
+    2. `f` can return any value.
+
+2. `contramap` must return a value of the same Functor


"a value of the same Functor"?

Good catch! I imagine this is a hangover from the Contravariant Functor name

joneshf · 2017-01-30T15:05:22Z

Looks like everything has been addressed here. I'm merging. Thanks everyone!

davidchambers · 2017-01-30T16:19:29Z

@joneshf, would you like to release v3.1.0?

adds contravariant functor to spec

d8ac952

rjmk mentioned this pull request Aug 21, 2016

adds a contravariant functor to spec fantasyland/static-land#16

Merged

adds to list of structures

7ba1e0c

scott-christopher reviewed Aug 22, 2016
View reviewed changes

rjmk added 2 commits September 6, 2016 09:17

Merge branch 'master' of github.com:fantasyland/fantasy-land

87cb883

* 'master' of github.com:fantasyland/fantasy-land: Add ChainRec specification (fantasyland#152) Add type signatures to spec (fantasyland#147)

Adds type signature; removes contravariant dependency in profunctor

c796a4e

Merge branch 'master' of github.com:fantasyland/fantasy-land

cc8caee

* 'master' of github.com:fantasyland/fantasy-land: change spec to require prefixed names (fantasyland#146)

rjmk added 2 commits November 12, 2016 12:52

Fix linting errors

35f03ef

Update figures

d3dc80d

davidchambers reviewed Nov 15, 2016

View reviewed changes

Update height of img in README

2537d28

Remove 'functor' from 'Contravariant' section name

162f45b

davidchambers reviewed Dec 19, 2016

View reviewed changes

Update algebra name in dependencies graph

0f39bb8

davidchambers reviewed Dec 20, 2016

View reviewed changes

Should be the last few fixes necessary for merge

fed119f

joneshf mentioned this pull request Jan 29, 2017

Contravariant functor PR fixes rjmk/fantasy-land#1

Merged

Merge pull request #1 from fantasyland/contravariant-functor-pr-fixes

38430f1

Contravariant functor PR fixes

davidchambers reviewed Jan 30, 2017

View reviewed changes

Avaq reviewed Jan 30, 2017

View reviewed changes

rjmk added 2 commits January 30, 2017 12:47

Merge branch 'master' into master

7c214a9

Update contramap laws

738a8a3

joneshf merged commit 5ac5a9f into fantasyland:master Jan 30, 2017

adds contravariant functor to spec #150

adds contravariant functor to spec #150

Conversation

rjmk commented Aug 21, 2016

Choose a reason for hiding this comment

rjmk Aug 22, 2016 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joneshf Aug 22, 2016 • edited

Choose a reason for hiding this comment

rjmk Aug 22, 2016 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rpominov commented Aug 22, 2016 • edited

rpominov commented Aug 22, 2016

rjmk commented Aug 22, 2016

rpominov commented Aug 22, 2016

rjmk commented Aug 22, 2016

rjmk commented Sep 1, 2016

Pro

Con

SimonRichardson commented Sep 5, 2016

rjmk commented Sep 6, 2016

SimonRichardson commented Sep 6, 2016

rjmk commented Sep 6, 2016

rpominov commented Sep 28, 2016

rpominov commented Sep 28, 2016

rjmk commented Sep 29, 2016

rpominov commented Oct 11, 2016

rjmk commented Nov 12, 2016

safareli commented Nov 12, 2016

Choose a reason for hiding this comment

evilsoft Nov 15, 2016 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

evilsoft Nov 15, 2016 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

safareli commented Nov 15, 2016 • edited

JeffDownie commented Dec 5, 2016 • edited

rjmk commented Dec 5, 2016 • edited

JeffDownie commented Dec 6, 2016

rjmk commented Dec 6, 2016

JeffDownie commented Dec 6, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joneshf commented Jan 30, 2017

davidchambers commented Jan 30, 2017

rjmk Aug 22, 2016 •

edited

joneshf Aug 22, 2016 •

edited

rjmk Aug 22, 2016 •

edited

rpominov commented Aug 22, 2016 •

edited

evilsoft Nov 15, 2016 •

edited

evilsoft Nov 15, 2016 •

edited

safareli commented Nov 15, 2016 •

edited

JeffDownie commented Dec 5, 2016 •

edited

rjmk commented Dec 5, 2016 •

edited