The Haskell Prime Wiki mentions the scoping of type variables in class instances, but only as an aside, and it is not even clear whether proposal 1 would support that feature or not. For me this once occurred as a matter of language expressiveness, i.e. I had once to switch from hugs to GHC, because I could not find a way of expressing in Hugs what I needed. The problematic piece of code was the following: instance (LUB a b c,Full c d) => Run(a->b) where interpret e a = (p1.p2)(evalExp [(e2.e1) a] (expand e)) where e1 = embed :: a->c e2 = embed :: c->d p2 = project :: d->c p1 = project :: c->b As you can see, this is using multi-parameter classes (and functional dependencies), and whether it is a matter of language expressiveness or not is probably connected to whether these features are around or not. Explanation: An instance "Run t" meant to provide an evaluation of expressions (some fixed type) that returns type t. This essentially worked by picking one of the approximants of the D_infty model that was "big enough" to do the evaluation in, embed inputs into that type, evaluate over there, and then project results out of it. The class instance above is the case for function types. To do this for a->b, I first need to find an upper bound into which I can safely embed/project types a and b - and that is c; then I find the next type into which I can embed c, at which I can do D_infty-style evaluation, and that is d. I get these types from deterministic multi-parameter classes. The embed/project functions come from the class instances LUB a b c and Full c d. There are instances giving me versions of embed with the same argument type but different result types, thus I need to be able to tell my program which ones to use when they are applied to a value of type a. Above, I do this with type annotations, but I need that the type variables I use here correspond to those of the class instance definition. In hugs, I was stumped. Stefan Kahrs