cannot use laws/functor to test composition property

identityʹ:

const identityʹ = t => eq => x => {
    const a = t(x)[map](identity);
    const b = t(x);
    return eq(a, b);
};

composition:

const composition = t => eq => x => {
    const a = t(x)[map](compose(identity)(identity));
    const b = t(x)[map](identity)[map](identity);
    return eq(a, b);
};

Consider a in composition:

a = t(x)[map](compose(identity)(identity))

Assume a proof for compose(identity)(identity) = identity:

a = t(x)[map](identity)

The identity property tells us that t(x)[map](identity) = t(x), so:

a = t(x)

Consider b in composition:

b = t(x)[map](identity)[map](identity)

The identity property tells us that t(x)[map](identity) = t(x), so:

b = t(x)[map](identity)
b = t(x)

I think all we’re actually proving is compose(identity)(identity) = identity, which isn’t at all what we’re hoping to prove. 😜

For composition to be useful I think it needs to take f :: b -> c and g :: a -> b as arguments.

[rpominov]

TIL: Parametricity also makes any function t :: (Functor f, Functor g) => f a -> g a natural transformation. In other words just by looking at signature we get t(v.map(f)) == t(v).map(f) for free. https://youtu.be/2LJC-XD5Ffo?t=31m22s

[joneshf]

I don’t have much want for it to be removed. So, if it’s worse, then no change 😃.

But honestly, you can do similar hacks in haskell with Data.Typeable. That doesn’t mean we need to stop believing the proof to be true. If a data type doesn’t respect parametricity, I don’t know that we should care about that data type.

I mean, the data type’s map procedure could look at the current timestamp and throw an exception only when it is congruent to 0 mod 123456789. You’d almost never see it blow up in practice, so both laws would pass, effectively, all of the time. Did the second law help us catch the problem?