How aggressive should desugaring be?

[goldfirere]

th-desugar doesn't currently try as hard as it could. But, it's not clear that trying harder would be a benefit. Here are some ways it could try harder:

• Always perform match flattening. This would greatly simplify the DPat type, which would contain only DConPa Name [Name], DLitPa ... and DWildPa. And, at the cost of some code duplication, DWildPa could be restricted to be only with literal patterns.
• There are many non-primitive literals. These could be removed (turning strings into lists of characters, and using primitive representations for numbers).
• Currently, patterns include bangs and laziness annotations. These could be desugared away.

I don't know the right answers here. My hunch is that being as aggressive as possible is good for singletons...

[RyanGlScott]

One unresolved question about match flattening is how it impacts the performance of libraries that consume the desugared output. singletons (one such consumer of th-desugar) used to make use of match flattening, but it later reverted it in goldfirere/singletons@87aa901. See goldfirere/singletons#113.

[RyanGlScott]

There is a similar question about Or patterns (which will debut in GHC 9.12) when thinking about the tradeoff between making DPat more minimal versus the complexity of the desugared output. In particular, template-haskell will have a Pat constructor for Or patterns:

data Pat
  = ...
  | OrP (NonEmpty Pat)

However, it's less clear if we need a corresponding DOrP constructor in th-desugar's DPat data type. After all, GHC itself desugars Or patterns to simpler patterns in Core. For example, if you have this:

data T = T1 String | T2 Int | T3 Int

stringOfT :: T -> Maybe String
stringOfT (T1 s)        = Just s
stringOfT (T2{}; T3{}) = Nothing

GHC will desugar stringOfT to Core that looks like this:

stringOfT :: T -> Maybe String
stringOfT t =
  case t of
    T1 s -> Just s
    T2 _ -> Nothing
    T3 _ -> Nothing

This Core function only makes use of simple constructor patterns. We could imagine doing a similar desugaring in th-desugar, but this quickly gets into the territory of match flattening, which is tricky for the reasons described above.

My inclination is to add DOrP to DPat, but to also implement support for desugaring away DOrPs in th-desugar's match flattening feature, which is currently optional.

EDIT: On the other hand, perhaps we don't even want to add support for DOrP at all. See #222 (comment).