- <.> mkWpLet (EvBinds (unitBag self_ev_bind))
- <.> mkWpLet ev_binds
-
- ; return (sc_op_id, noLoc sc_op_bind) }
-\end{code}
-
-Note [Recursive superclasses]
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-See Trac #1470 for why we would *like* to add "self_dict" to the
-available instances here. But we can't do so because then the superclases
-get satisfied by selection from self_dict, and that leads to an immediate
-loop. What we need is to add self_dict to Avails without adding its
-superclasses, and we currently have no way to do that.
-
+ <.> mkWpLet ev_binds
+
+However this means that if we later encounter a situation where
+we have a [Wanted] dw::D [a] we could solve it thus:
+ dw := dfun dw
+Although recursive, this binding would pass the TcSMonadisGoodRecEv
+check because it appears as guarded. But in reality, it will make a
+bottom superclass. The trouble is that isGoodRecEv can't "see" the
+superclass-selection inside dfun.
+
+Our solution to this problem is to change the way ‘dfuns’ are created
+for instances, so that we pass as first arguments to the dfun some
+``silent superclass arguments’’, which are the immediate superclasses
+of the dictionary we are trying to construct. In our example:
+ dfun :: forall a. (C [a], D [a] -> D [a]
+ dfun = \(dc::C [a]) (dd::D [a]) -> DOrd dc ...
+
+This gives us:
+
+ -----------------------------------------------------------
+ DFun Superclass Invariant
+ ~~~~~~~~~~~~~~~~~~~~~~~~
+ In the body of a DFun, every superclass argument to the
+ returned dictionary is
+ either * one of the arguments of the DFun,
+ or * constant, bound at top level
+ -----------------------------------------------------------
+
+This means that no superclass is hidden inside a dfun application, so
+the counting argument in isGoodRecEv (more dfun calls than superclass
+selections) works correctly.
+
+The extra arguments required to satisfy the DFun Superclass Invariant
+always come first, and are called the "silent" arguments. DFun types
+are built (only) by MkId.mkDictFunId, so that is where we decide
+what silent arguments are to be added.
+
+This net effect is that it is safe to treat a dfun application as
+wrapping a dictionary constructor around its arguments (in particular,
+a dfun never picks superclasses from the arguments under the dictionary
+constructor).
+
+In our example, if we had [Wanted] dw :: D [a] we would get via the instance:
+ dw := dfun d1 d2
+ [Wanted] (d1 :: C [a])
+ [Wanted] (d2 :: D [a])
+ [Derived] (d :: D [a])
+ [Derived] (scd :: C [a]) scd := scsel d
+ [Derived] (scd2 :: C [a]) scd2 := scsel d2
+
+And now, though we *can* solve:
+ d2 := dw
+we will get an isGoodRecEv failure when we try to solve:
+ d1 := scsel d
+ or
+ d1 := scsel d2
+
+Test case SCLoop tests this fix.
+