GHC Trac Home
GHC Git Repos
Report a bug
Mailing Lists & IRC
The GHC Team
GHC Status Info
Tickets I Created
Patches for review
New Feature Req
side by side
lines around each change
Show the changes in full context
White space changes
Apr 20, 2007 2:00:18 PM (
Incidentally, if during conversion we come across a type declaration that we don't know how to convert (as it uses fancy extensions), we just don't generate a conversion.
Note that basic types, such as `Int` and friends, would have `tyConCC` set to `Nothing`, which is exactly what we want.
=== Class declarations ===
=== Generating conversions ===
Whenever we had `convert t e` above, where `t` is an unconverted type and `e` a converted expression, we need to generate some conversion code. This works roughly as follows in a type directed manner:
convert T = id , if tyConCC T == Nothing
= to_T , otherwise
convert a = id
convert (t1 t2) = convert t1 (convert t2)
convert (t1 -> t2) = createClosure using (trevnoc t1)
and (convert t2) on argument and result resp.
where `trevnoc` is the same as `convert`, but using `from_T` instead of `to_T`.
The idea is that conversions for parametrised types are parametrised over conversions of their parameter types. Wherever we call a function using parametrised types, we will know these type parameters (and hence can use `convert`) to compute their conversions. This fits well, because it is at occurences of `Id`s that have `idCC == Nothing` where we have to perform conversion.
The only remaining problem is that a type parameter to a function may itself be a type parameter got from a calling function; so similar to classes, we need to pass conversion functions with every type parameter. So, maybe we want to stick `fr` and `to` into a class after all and requires that all functions used in converted contexts have the appropriate contexts in their signatures.