On Mon, Jun 30, 2014 at 5:36 PM, Jonathan S. Shapiro <[email protected]> wrote:
> Geoffrey:
>
> Good question. One of the problems we have with the BitC mailing list is
> that these discussions happen on the list and then later we can't search
> them. I've just revised the robots.txt file on those sites to allow crawling
> for bing and google. Let's see if that helps.
>
> To answer your question:
>
> 1. For a while, I had concluded that type classes flatly didn't work at all
> at scale. I've since come to a design position that I think will make them
> workable.
>
> 2. Original BitC had both type classes and "capsules" (which were at one
> point called objects). A capsule is very similar to an interface, except
> that you can't do a dynamic cast back to the original object.
>
> 3. The concern about class support is mainly driven by interoperability. But
> also, the main objection to classes from a type system perspective had been
> that they push us into a type system similar to F<, with all of the
> inference issues that carries. The thing is: once we introduce regions, we
> are pushed into subtype inference in that part of the system in any case. At
> some point it was sort of like "well, in for a penny, in for a US National
> Debt".
Thanks, that makes sense, and at least Scala stands as an example of a
widely used language with full subtyping.
>> At some point the decision was made that some sort of class support
>> was a more practical route.
>
>
> I wouldn't say that. It was more that I was feeling pressure to succumb.
> Also, because classes carry their methods with them, they avoid the
> resolution issues that plague type classes.
Yeah, I have a personal grudge against those issues.
>> The reason I ask is that (modulo issues of checked upcasts) interfaces
>> and type class existentials seem isomorphic.
>
>
> Oh no, not at all! For starters, type classes are not types. Second, the
> resolution rules are drastically different. Third: type classes do not
> address the need for existential where interfaces are an existential
> wrapping mechanism. In fact, it was staring at the capsule mechanism that
> made me realize that.
>
> Type classes with implicits is another thing. Once you can carry around a
> designator for a particular instance, the type class is the instance of the
> type.
Thanks, that's a useful clarification. I was referring to isomorphism
after some sort of dictionary passing transform has occurred, but I
suppose that's too late. Type classes with implicits are closer since
there the programmer in some sense "sees" the dictionary passing.
Implicits still need extra existential support to get heterogeneity,
though.
One worry I have is that if existentials are "wrapped up inside
interfaces" rather that flowing around freely, some of the benefits of
type classes over object oriented programming will be lost.
Specifically, if you have a group with operator
* : a -> a -> a
a type knows that the three a's must be the same. For type classes
with implicits the code would unpack the implicit, throw around a's
freely, and then pack it back up as necessary at the end, ensuring
that all the a's are the same when they need to be.
This problem goes away if the type only occurs once in any type
signature, which is often in the case for imperative code, which might
mean that interfaces push people in that direction. I believe Scala
and the vObj calculus can handle such things, but that requires
interfaces to include type fields.
Geoffrey
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
