[bitc-dev] Why Type Classes?

[Jonathan S. Shapiro]

Is it possible for BitC on CLI to satisfy the representation requirements
for unions? I don't believe so, and this strikes me as an area where CLI
can/should be improved.

On Sat, Nov 15, 2008 at 12:31 AM, Eric Northup <digitale at digitaleric.net>wrote:

> 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?
> _______________________________________________
> bitc-dev mailing list
> bitc-dev at coyotos.org
> http://www.coyotos.org/mailman/listinfo/bitc-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20081115/17c072b3/attachment.html