Labelled effects

[robrix]

This PR defines a module for labelled effects, allowing some pretty powerful patterns applying injectivity/type dependencies to effects. For example:

1. Stock effects such as Reader and State can be distinguished by means of arbitrary labels, which can be much more convenient than ScopedTypeVariables in many cases.

2. Type inference can be improved by the same means for many parametric effects if and as desired.

3. Effect parameters can be made dependent on the carrier without concretely mentioning it; this amounts to the ability to associate arbitrary types with effects via a label.

4. Equivalently, ambiguities can be resolved for effect parameters via a label.

Labels offer a super flexible means of applying injectivity to uniquely determine some effect from an arbitrary label, without having to define new classes anywhere; indeed, existing effects, operations, and carriers can be lifted into their labelled counterparts as-is.

This is in quite good shape for use, but there’s still some work to do before we merge this:

• API documentation.
• Document the sorts of patterns this enables; e.g. how to solve interesting inference or ambiguity problems.
• Maybe bake in labelled Reader/State operations?
• Changelog entry.
• Tests.
• Laws? What would they even look like…? This isn’t really meaningful beyond the labelled Reader/State operations.
• Changelog entries for Control.Effect.Reader.Labelled and Control.Effect.State.Labelled.
• Hackage release. Going to do this in a separate PR after Benchmark Reader and inline its requests. #347 is in.

[patrickt]

Fantastic work, @robrix. I’m really excited that labelled effects were such a small addition in terms of API, because the advancements in expressivity are quite profound compared to the dummy-newtype approach.