-- | Absent, {0}. Pretty-printed as A.

 pattern C_00 :: Card

 pattern C_00 = Card 0b001

 pattern C_10 :: Card

 pattern C_10 = Card 0b000

 -- | Strict and used once, {1}. Pretty-printed as 1.

 variables of 'rhs'.

 So we have the simple definition

 Historically, when we had `lubBoxity = _unboxedWins` (see Note [unboxedWins]),

 we had a more complicated definition for deferAfterPreciseException to make sure

    case <I/O operation> of

       (# s', r) -> f x

 we'd get an *unboxed* demand on `x` (because we let Unboxed win),

 which led to #20746.  Nowadays with `lubBoxity = boxedWins` we don't need

 the complicated definition.

         a single DmdType

 (Nevertheless we dignify DmdSig as a distinct type.)

 Here `n` is called the "demand-sig arity" of the DmdSig.  The signature means:

   * If you apply `f` to n arguments (the demand-sig-arity)

   * then you can unleash demands d1..dn on the arguments

 Also see Note [Demand type Divergence] for the meaning of a Divergence in a

 demand signature.

 arguments.

 For example, the demand transformer described by the demand signature

 says that when the function is applied to two arguments, it

 If this same function is applied to one arg, all we can say is that it

 uses x with 1L, and its arg with demand 1P(L,L).

 The abstract transformer (let's call it F_e) of the if expression (let's

 call it e) would transform an incoming (undersaturated!) head sub-demand A

      SubDemand ---F_e---> DmdType

 Let's assume that the demand transformers we compute for an expression are

 correct wrt. to some concrete semantics for Core. How do demand signatures fit

 it's sound to unleash them.

 Fortunately, we can formalise the rules with Galois connections. Consider

 the actual abstract transformer of f's RHS for arity 2. So, what happens is that

 we abstract *once more* from the abstract domain we already are in, replacing

 the incoming Demand by a simple lattice with two elements denoting incoming

 and F_f being the abstract transformer of f's RHS and f_f being the abstracted

 abstract transformer computable from our demand signature simply by

 where multDmdType makes a proper top element out of the given demand type.

     incoming sub-demand   |  demand type

     --------------------------------

 Note that in the first example, the depth of the demand type was *higher* than

 the arity of the incoming call demand due to the anonymous lambda.

     a polymorphic sub-demand of the same letter: E.g. ``L`` is equivalent to

     ``LL`` by expansion of the single letter demand, which is equivalent to

     ``LP(LP(..))``, so ``L``\s all the way down. It is always clear from

     **Demand signatures**

         maybe n _ Nothing  = n

         maybe _ s (Just a) = s a

     according to ``L``". The expression ``f `seq` f 1`` puts ``f`` under

     demand ``SC(1,L)`` and serves as an example where the upper bound on

     evaluation cardinality doesn't coincide with that of the call cardinality.