-The <code>TyVar</code> case is self-explanatory. The
-<code>MutTyVar</code> case is used only during type checking. Then a
-type variable can be unified, using an imperative update, with a type,
-and that is what the <code>IORef</code> is for. The <code>Bool</code>
-field records whether the type variable arose from a type signature,
-in which case it should not be unified with a type (only with another
-type variable).
+The <code>TyVar</code> case is self-explanatory. The <code>MutTyVar</code>
+case is used only during type checking. Then a type variable can be unified,
+using an imperative update, with a type, and that is what the
+<code>IORef</code> is for. The <code>TcType.TyVarDetails</code> field records
+the sort of type variable we are dealing with. It is defined as
+<pre>
+data TyVarDetails = SigTv | ClsTv | InstTv | VanillaTv
+</pre>
+<code>SigTv</code> marks type variables that were introduced when
+instantiating a type signature prior to matching it against the inferred type
+of a definition. The variants <code>ClsTv</code> and <code>InstTv</code> mark
+scoped type variables introduced by class and instance heads, respectively.
+These first three sorts of type variables are skolem variables (tested by the
+predicate <code>isSkolemTyVar</code>); i.e., they must <em>not</em> be
+instantiated. All other type variables are marked as <code>VanillaTv</code>.