[bitc-dev] Why Type Classes?

[Jonathan S. Shapiro]

Yes. The problem is in staying within the safe subset.

As far as I know, CLR does not provide a means to check a compiler-provided
proof, so "amenable to local verification" must be taken a bit loosely.

On Sat, Nov 15, 2008 at 12:53 PM, Rodrigo Kumpera <kumpera at gmail.com> wrote:

> The CLR admits overlapping valuetypes at arbitrary offsets.
> For (pointers to) reference types it's invalid to have partial overlapping
> and even so,
> it's not part of the defined safe subset.
>
> The main issue with unions on the CLR is how to encode safety guarantees
> that are amendable to local
> verification.
>
>
> On Sat, Nov 15, 2008 at 1:34 PM, Jonathan S. Shapiro <shap at eros-os.com>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>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
>>>
>>>
>>
>> _______________________________________________
>> bitc-dev mailing list
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20081115/602e644b/attachment.html