TH Generation of LabelOptic instances for prisms on sum-types

[nikita-volkov]

Which for the following type:

data ApiError =
  InvalidDataApiError |
  RejectedApiError Text |
  UnauthorizedApiError Int Text

would generate instances like the following:

instance LabelOptic "invalidData" A_Prism ApiError ApiError () () where
  labelOptic =
    prism' (const InvalidDataApiError)
      \ case
        InvalidDataApiError -> Just ()
        _ -> Nothing

instance LabelOptic "rejected" A_Prism ApiError ApiError Text Text where
  labelOptic =
    prism' RejectedApiError
      \ case
        RejectedApiError a -> Just a
        _ -> Nothing

instance LabelOptic "unauthorized" A_Prism ApiError ApiError (Int, Text) (Int, Text) where
  labelOptic =
    prism' (\ (a, b) -> UnauthorizedApiError a b)
      \ case
        UnauthorizedApiError a b -> Just (a, b)
        _ -> Nothing

Allowing to address this sum-type like this:

> preview #rejected (RejectedApiError "alsdkjf")
Just "alsdkjf"

Benefits

1. Makes prisms conform to the same convention as of record labels.
2. Avoids polluting the namespace with generated functions.
3. Avoids the awkwardness of the _PrismName naming convention.

[adamgundry]

This is essentially what makePrismLabels does, isn't it? Modulo some questions about how to map constructor names onto label names...

[nikita-volkov]

How about having a declareOpticLabels function, which would declare instances for both sum-types and records?

[arybczak]

Declaring a type within declateFieldLabels and then calling makePrismLabels after does the job (see #355).

Interesting proposition. I imagine that generation of optics for both fields and constructors for a data type is useful mostly when you have partial field accessors, but declare flavor gets rid of unsafe partiality by not exposing accessors and giving you affine traversals instead.

If only we had viable (i.e. not conflicting with strict fields) way to construct values of such types with optics...

[nikita-volkov]

I've been suggesting it so that there'd be a single function to call no matter what structure you're dealing with. More so, it would allow to pass a bunch of type declarations (your whole domain model ideally) into a single call of declareOpticLabels.