On Fri, Nov 14, 2008 at 8:52 AM, Rodrigo Kumpera <span dir="ltr"><<a href="mailto:kumpera@gmail.com">kumpera@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The naive approach to support generics by a CLR VM is to expand every instantiation and produce<br>native code for all variations....</blockquote><div><br>Yes. We're aware of that issue and several others. The goal, for the moment, is simply to get a complete implementation of the language finished. The optimization you mention, and several others, will follow. Naive is better than nothing. :-)<br>
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">What the VMs support [1] is sharing code for all reference types, which expands to pretty much the same thing.<br>
For valuetypes this sharing is non-trivial so no VM does it.</blockquote><div><br>For us that will be important in lieu of inheritance, but we see how to do it straightforwardly, and we even see how to do it in a type-safe way.<br>
<br>The problem I anticipate is that our strategy for type class instantiation probably needs to be revised for a non-kernel implementation into something closer to a v-table style of implementation.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
>From my narrow understanding of typeclasses, they can be seen as interfaces that don't need to be explicitly<br>
implemented by the target types. So the problem of sharing code for typeclasses is then pretty much the same<br>as for sharing for generics types with bounds (restrictions on the type arguments) [2].</blockquote><div><br>
Not quite, because of size-based polymorphism, but yes, that's the general idea.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The main issue we had within mono was carrying runtime information around to make introspection works. I<br>
don't know how much introspection/reflection support BitC has, but it would be nice if you could explain how<br>do you plan on tackle on these issues.</blockquote><div><br>Read-only introspection isn't much of a problem. Read-write introspection is such a disaster from an assurance perspective that we have very explicitly excluded it.<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">BTW, I think BitC would map very well on top of the CLR given it had interface injection support.</blockquote>
<div><br>Actually, BitC cannot run on either CLR or JVM, because there are representation requirements that neither platform can meet. If those requirements are set aside, then yes, I think it would work fine on either platform.<br>
<br></div><br></div>