On Sat, Feb 12, 2011 at 7:26 AM, Sandro Magi <[email protected]>wrote:
> On 2011-02-12 2:16 AM, Jonathan S. Shapiro wrote: > > Of course, this means that interfaces subsume type classes. > > I wouldn't necessarily conclude that. I would say that interfaces > conflate overloading with encapsulation. Since interfaces have no relationship to overloading, I'm not sure how you are getting that. > Can you specify an interface > that exposes the concrete type rather than hides it? If you mean the concrete type of the implementing class/capsule, then the answer is no. But (a) all of the *other* types expressed in the interface are concrete (or at least parametrically forall-abstracted in the usual way) and (b) if all members of an interface are *static* members then there isn't any encapsulated concrete type. So if what you are asking is: can we can construct an interface that does not encapsulate a type, the answer is: yes. > Is interface > instantiation implicit driven by constraints as type classes are? Until we start looking at how interfaces relate to type classes, the answer is "no", because interfaces are always passed as explicit arguments. In effect, they are just abstract classes. The fact that interfaces appear to *specify* everything that is specified in a type class is mainly of interest from a type system perspective. That is: the apparent relationship might reduce the size of the core type system, and consequently the size and complexity of the compiler. Whether the two are presented as the same idea at the source code level has a lot more to do with how closely these ideas seem related in the programmer's head. > Did I > miss the message with the concrete proposal for interfaces? If there is > a concrete proposal I can read, that may clear up some confusion. There isn't yet, but that probably means that I'm overdue to generate one. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
