fantasyland / fantasy-land

Specification for interoperability of common algebraic structures in JavaScript
MIT License
10.08k stars 373 forks source link

Clarify how to properly test compliance? #243

Closed glebec closed 6 years ago

glebec commented 7 years ago

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 commented 7 years ago

Will fantasyland/fantasy-laws#1 get us some of the way there, @glebec?

glebec commented 7 years ago

@davidchambers — ah, I didn't notice that PR.

It's definitely a step in that direction especially assuming that the README outlines how developers can use the law functions to confirm their libraries work correctly.

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").

If a more integrated and thorough spec built on top of the laws sounds like something we'd like to add to Fantasy-Land, I'd be interested in taking a crack at it. I don't know if that would live in this repo, the Fantasy-Laws repo, or a new repo; I also don't know if we'd have preferences in terms of testing framework etc. I'm happy to hear your opinions.

davidchambers commented 7 years ago

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
davidchambers commented 6 years ago

@glebec, fantasy-laws is now available via npm. Can this issue be closed, do you think?

glebec commented 6 years ago

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.