[bitc-dev] Type Classes: Pragmatics Questions

[Jonathan S. Shapiro]

On Tue, 2005-07-19 at 23:36 -0700, Mark P Jones wrote:
> This could indeed be a problem if you don't take steps to address it.

I think that in most of the programs where it is likely to be an issue,
we are happy to state types.

> For example, instead of asking for a type
> signature, you could add an extra "overloaded" keyword and only allow
> the definition of "f" above to be overloaded if it is written as:
> 
>     overloaded f x = x + 1

Another option would be to declare at the location of the typeclass
definition that the typeclass should not be automatically inferred --
with the effect that it's use must be declared. For type classes close
to ground this might make sense.

>   - specialization is a whole program analysis, which means that the
>     technique might have problems scaling to deal with large systems.
>     (This doesn't rule out separate compilation, but it does mean that
>     you are going to have to rely on some fairly smart linker/whole
>     program optimizer ...)  Fortunately for us, our interest is in
>     compiling a *micro*kernel ... with any luck, our programs won't
>     be too big (assurance would become a problem too in that case)
>     and whole program analysis should still be a viable option...

This makes me inclined to rule out specialization, because it also seems
to rule out *dynamic* linking. In the BitC context, our objectives are
not restricted to compiling a microkernel. There are certainly cases
where we will engage in whole-program analysis, but I would prefer a
design that does not obligate us to do so to obtain reasonable results.

shap