Contracts for resolvers are inflexible

[jackfirth]

Offset/gap/overlay resolvers are functions with a particular kind of signature. If the API changes in a way that new parameters need to be added, removed, or moved around, all client code using custom offset resolvers breaks. The details of a resolver's implementation are only useful to Gregor users constructing their own resolvers - most users don't need anything beyond the already provided ones. Instead Gregor could provide constructors that accept the resolver functions and produce opaque resolver values instead. This has a number of advantages:

• The documentation can be simpler, particularly the documentation of the Gregor-provided resolvers, since their function contracts don't need to be mentioned.
• If the contract for resolvers changes, client code breaks, but if client code has to pass their resolver function to a constructor, the constructor can wrap old resolvers by rearranging parameters, supplying default behavior, etc
• Resolvers provided by Gregor can avoid being wrapped in contracts.
• Resolvers can't be used outside Gregor functions. This is a mixed bag - clients lose some flexibility, but gain better error messages and checking since it becomes much harder to use a non-resolver function where you meant to use a resolver and vice-versa.

This is something that bit me in the lens package a while back. It would be tricky to add this to Gregor in a backwards compatible way, but it could be worth it. Let me know what you think!