scoped type variables in class instances
S.M.Kahrs
S.M.Kahrs at kent.ac.uk
Thu Jan 26 10:17:19 EST 2006
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
More information about the Haskell-prime
mailing list