[bitc-dev] Type Classes: Pragmatics Questions
Jonathan S. Shapiro
shap at eros-os.org
Wed Jul 20 10:46:28 EDT 2005
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.
More information about the bitc-dev