Is really necessary specify "No parts of <...> value should be checked"?

Hi!

After reading #210, I still don’t understand why these kind of law are needed. The topic starts talking about "No parts of b return value should be checked. But, finally, it concludes that the implementations that perform this kind of checks are breaking other laws.

For example:

class Maybe {
    static of(val) {
      return new Just(val);
    }
}

class Just extends Maybe {
    constructor(val) {
        super()
        this.val = val;
    }
    map(f) {
        const r = f(this.val)
        return r === null ? new Nothing() : Maybe.of(r);
    }
}

class Nothing extends Maybe {
    map(f) {
        return this;
    }
}

This implementation breaks No parts of f's return value should be checked. However, it is also breaking the composition law:

const f = x => x === 2 ? null : x;
const g = x => x === null ? 2 : x;

Maybe.of(2).map(f).map(g) // Nothing {}
Maybe.of(2).map(x => g(f(x))) // Just {val: 2}

Then, I wonder if No parts of f's return value should be checked is a really necessary law. For me it’s a weird law because is talking about the implementation. For example these two implementations of Maybe:

class Just extends Maybe {
    ...
    map(f) {
        const r = f(this.val);
        return Maybe.of(r);
    }
}

and

class Just extends Maybe {
    ...
    map(f) {
        const r = f(this.val)
        return r === null ? Maybe.of(r) : Maybe.of(r);
    }
}

behave the same and are identity and composition law compliant. However, the second breaks the No parts of f's return value should be checked and is not functor lawful. It doesn’t make sense for me.

Cheers!

[Avaq]

I think the law is there to serve as a more direct deterrent for unlawful implementations. Specifically, Maybe.of = x => x ? Just(x) : Nothing kind of implementations were very common.

I also believe that the law is redundant with regards to preventing these bad implementations, and in fact, overly restrictive otherwise. Sanctuary breaks this law in multiple ways:

1. Input type checking
2. Constrained type instances

In my view, both of these cases should be allowed.

[CrossEye]

I guess I’d simply like to see a section in the prefix similar to the “Terminology”, “Type Signatures”, etc. ones, something like:

forAll

Parametric polymorphism is essential to these algebras. When the rules for any type are specified as applied to all values (forall a or ∀ a) the rule must hold for any Javascript values unless otherwise specified. This implies, for instance, that code that behaves differently for the null or undefined value than for other values is unlikely to comply with the rule.

… and then simply use <forall ...> where needed.