Constraints should be open

[treeowl]

The Constraints type family is closed. It seems that both conceptually and practically, it should be open.

[phadej]

Optics hierarchy is closed in optics. This a design choice (somewhat indirectly mentioned in https://hackage.haskell.org/package/optics-0.4.1/docs/Optics.html#g:4, opaque design leads to closed hierarchy). And in fact OpticKind could be a data (i.e. closed kind) IMO, but we decided to have OpticKind = Type for now (#58), because GHC prints ugly ticks for promoted types. (We might revisit that once https://gitlab.haskell.org/ghc/ghc/-/issues/20531 is implemented, optics being a motivation point).

[arybczak]

To be fair, Constraints being open wouldn't change anything in the past because we relied on JoinKinds being a closed type family. But now that it's a class, if the Constraints and EliminationForms are made open, then IIUC it would be possible for a third party to add a new optic kind 🤔

[phadej]

The addition is not very compositional though. User A can add their optic easily, and User B can add theirs, but if C want to use both, they will need to make A and B to talk to each other.

And you cannot add something in between, like Traversal1.

[treeowl]

@phadej, why can't you add something in between? The diamond problem is ... annoying.

[phadej]

why can't you add something in between?

You are right, maybe Traversal1 one can be added in, as we don't over-approximate JoinKinds, i.e. it's a "Join" i.e. least upper bound of known optics. (I was thinking about lens, where Prism and Lens composition is Traversal, and not AffineTraversal, as there isn't AffineTraversal in lens).

(EDIT: this is another example of non-compositionality, all additions have to preserve the "leastness" of upper bounds in JoinKinds; have to consider the global structure to keep it sane)

[treeowl]

In principle, I think it should be possible to do much more with in-betweens than lens can, through suitable fudging of Is.