[bitc-dev] Why Type Classes?

[Eric Northup]

Rodrigo Kumpera wrote:
> The naive approach to support generics by a CLR VM is to expand every 
> instantiation and produce
> native code for all variations. This is far from optimal as the 
> generated bloat usually interacts pretty bad
> with the icache.
>
> What the VMs support [1] is sharing code for all reference types, 
> which expands to pretty much the same thing.
> For valuetypes this sharing is non-trivial so no VM does it.
The very first CLR VM to support generics actually did share code for 
compatible (from the perspective of the GC's reference visitor) 
structure types - see section 4.1 of 
http://research.microsoft.com/projects/clrgen/generics.pdf .

[...]
> BTW, I think BitC would map very well on top of the CLR given it had 
> interface injection support.
I agree that a CLI target would be interesting for BitC.  No particular 
support for interface injection is necessary - I can imagine several 
direct embeddings of type classes into CLI interfaces.  Polyinstantation 
or method dictionaries could also be done while targeting the CLI, thus 
treating it as a lower-level IL.  The lower-level IL might potentially 
be compatible with the CIL subset supported by the gcc cli front-end.


I didn't quite understand what Shap said about sometimes needing to 
dynamically fabricate a dictionary, though.  Is that a consequence of 
separate compilation?