non/spire — pull request #83 by larsrh (2013-03-05 21:19:46+00:00)
Title: More robust & flexible law checking

The most important part of this pull request is the `SpireProperties` trait. That trait abstracts over the various ways how the laws of a type class can depend on the laws of other type classes.

For that matter, we divide type classes into ''kinds'', where the classes of one kind share the number of operations and meaning. For example, `Semigroup`, `Monoid` and `Group` all belong to the same kind. On the other hand, their additive variants also belong to a common kind, but to a different one.

Consider this example hierarchy:

```
Semigroup
| \
Monoid AdditiveSemigroup
| \ |
Group AdditiveMonoid
\ |
AdditiveGroup
```

They all define their own laws, as well as a couple of parent classes. If we want to check the laws of `AdditiveGroup`, we want to avoid checking properties twice, i.e. do not want to check `Monoid` laws via `Group` and also via `AdditiveMonoid`.

To address this problem, we define the parent in the same kind as ''parent'', and other parents as ''bases''. In this example, the parent of `AdditiveGroup` is `Group`, and its only basis is `Group`. On the other hand, the parent of `Group` is `Monoid`, and it does not have any bases.

The set of all properties of a certain class is now defined as union of these sets:
- the properties of the class itself
- recursively, the properties of all its parents (ignoring their bases)
- recursively, the set of ''all'' properties of its bases

Looking at our example, that means that `AdditiveGroup` includes the `Monoid` law only once, because it is the parent of its basis. The same laws are ignored by its parent `AdditiveMonoid`, hence no redundant checks occur.

Of course, classes can have multiple parents and multiple (named) bases. The only requirement here is that ''inside one kind'', the identifier of a property is unique, since duplicates are eliminated. To avoid name clashes ''between different kinds'', the names of properties pulled in via a basis are prefixed with the name of the basis.

----

_Handling of "not-quite" instances_

Consider the `Field` instance for `(Rational, Rational)`, which treats the tuple elements separately. This is not actually a field, since `(0, 1)` has no inverse but is not the zero element. We can exclude those cases in the tests:

```scala
checkAll(
"(Rational,Rational)",
RingLaws[(Rational, Rational)].
withPred(Predicate { case (r1, r2) =>
val P = implicitly[Predicate[Rational]]
P(r1) && P(r2)
}).
field
)
```