[bitc-dev] Why Type Classes?

[Sandro Magi]

The CLI does support C-style unboxed union types, see Section 6.2:

http://research.microsoft.com/~emeijer/Papers/CLR.pdf

Whether it provides *enough* control for the purposes of BitC I'm not sure.

Sandro

Jonathan S. Shapiro wrote:
> 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
> <mailto: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 <mailto:bitc-dev at coyotos.org>
>     http://www.coyotos.org/mailman/listinfo/bitc-dev
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> bitc-dev mailing list
> bitc-dev at coyotos.org
> http://www.coyotos.org/mailman/listinfo/bitc-dev