| 53 | |

| 54 | 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: |

| 55 | {{{ |

| 56 | convert T = id , if tyConCC T == Nothing |

| 57 | = to_T , otherwise |

| 58 | convert a = id |

| 59 | convert (t1 t2) = convert t1 (convert t2) |

| 60 | convert (t1 -> t2) = createClosure using (trevnoc t1) |

| 61 | and (convert t2) on argument and result resp. |

| 62 | }}} |

| 63 | where `trevnoc` is the same as `convert`, but using `from_T` instead of `to_T`. |

| 64 | |

| 65 | 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. |

| 66 | |

| 67 | 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. |