[darcs-devel] [patch2166] cleaning up Arbitrary instances

[Ganesh Sittampalam]

Ganesh Sittampalam <ganesh at earth.li> added the comment:

> Still, the fact that you could generalize the instance for pairs so that
> it works for triples, too, and thus could remove arbitraryTriple,
> /suggests/ that perhaps we can similarly do away with all the triple
> instances. Is there a simple explanation why this is not possible?

I think there are a few different things going in different places.

In the first patch ("get rid of arbitraryTriple") the code pattern for
pairs and triples in that particular place was pretty regular and didn't
depend on the fact that the patch types were all the same. So really it
was just about generalising that code and hence reducing repetition.

That isn't always the case. Most importantly, Pairs are a bit special:
when we get to the ArbitraryState class, the arbitraryStatePair member
is needed because we want to specialise generation for (p :> p)
specifically, ultimately to call 'aPrimPair' for each of the different
underlying primitive types.

That specialisation in turn leads to an ArbitraryWS instance for Pair
that is different from all the other ArbitraryWS instances:

> instance ArbitraryModel p => ArbitraryWS (Triple p) where
>   arbitraryWS = makeWS2Gen aSmallRepo

(and the same code for most other types)

> instance (RepoModel (ModelOf p), ArbitraryState p) =>
>                                    ArbitraryWS (Pair p) where
>   arbitraryWS = arbitraryWSPair

So for this code, we can't trivially replace the handling of pairs and
triples with something more compositional, because we actually want
different behaviour.

That said I'm sure there's still room for simplification. I'm not really
happy with the existence of "glue" classes like ArbitraryWS and similar
the Pair/Triple types.

But it was relatively easy to get to this point by some step-by-step
refactorings and I hope that it helps us spot more cleanup opportunities
in future.

One thought I just had is that maybe the 'aPrimPair' concept itself
could be generalised, because we'd probably like something similar for
triples too. Maybe we could propagate forward properties of the
left-hand side of :> to influence generation of the right-hand side.

__________________________________
Darcs bug tracker <bugs at darcs.net>
<http://bugs.darcs.net/patch2166>
__________________________________