Clarify how to properly test compliance?

I am new to Fantasy-Land and algebraic types in general, so please correct me if any of the following is incorrect or off-base.

One of the nicest things a specification can do is provide a compliance suite for implementers to confirm their work, if at all possible. As far as I can see, FL doesn’t quite include such a suite.

This repo includes a set of namespaced laws in curried function form (not all of the same type signature), which return booleans. That seems somewhat on the way towards a compliance suite, and indeed FL’s own test.js appears to check that the laws hold for its internal/example Id and Sum types.

It would seem to be possible for any implementer to import those laws in their own project and directly invoke the functions with correct arguments (as deduced from reading the source code) — which is perhaps the intent of the authors of this project. However, I wonder if it is not possible to provide something more cohesive, documented, straightforward, and foolproof?

For example, the Promises/A+ organization provides a compliance suite which can be run programmatically using a thin adapter module. The implementer does not need to know how to properly test their Promise library, just how to bridge their API to the expected API.

Is there any reason why FL cannot or would not follow suit (no wordplay intended)? I am just curious.

[davidchambers]

One thing to note is that the laws are not the totality of the spec, considering the spec requires additional constraints (e.g. “A value that implements the Ord specification must also implement the Setoid specification”).

Good point. This is actually encoded in sanctuary-type-classes. For example, this is the definition of Z.Monoid:

//# Monoid :: TypeClass
//.
//. `TypeClass` value for [Monoid][].
//.
//. ```javascript
//. > Monoid.test('')
//. true
//.
//. > Monoid.test(0)
//. false
//. ```
var Monoid = $('Monoid', [Semigroup], {empty: Constructor});

I’ve added an item to the to-do list in fantasyland/fantasy-laws#1:

• Verify dependencies as discussed in fantasyland/fantasy-land#243

[glebec]

Given that I’m not actively looking at this project in any case, from an issue author perspective I am certainly okay with closing the issue. As to whether fantasy-laws satisfies the goals stated above, at first glance it looks sufficient, though I haven’t examined it exhaustively.