Thanks, Sandro. My impression is that three things resolve the concern:
1. I do not anticipate interface subtyping in BitC. 2. Module-level interfaces do not have instances (values). More precisely: a module-level interface at a type has exactly one value: the module implementation. 3. Interface types are not polymorphically recursive. On Thu, Jan 9, 2014 at 10:51 AM, Sandro Magi <[email protected]> wrote: > On 09/01/2014 1:35 PM, Jonathan S. Shapiro wrote: > >> So far, we have said that the only things in an interface are static and >> non-static methods. I want to identify a bunch of other things that can >> (and in some cases must) live in an interface: >> >> Type definitions and declarations >> Constant definitions (e.g. for enum and/or union labels) >> Attributes /declarations/ (which we have discussed). >> >> > As soon as you start including type definitions in interfaces, you're > going down the path of first-class modules. > This is dangerous territory! Andreas's post in the LtU thread you started > gives a short survey: > > http://lambda-the-ultimate.org/node/4865#comment-78086 > > Basically, it seems like you only avoid the undecidability if at least one > of the following holds: > > 1. interfaces are not first-class (like type classes) > 2. interface subtyping doesn't need to be decided > 3. type components of interfaces can't be abstract > 4. abstract type components of interfaces can't themselves be interfaces > > There's seemingly no good tradeoff given your desired direction. #2 might > be the most palatable, as I believe the undecidability results from > structural typing. A purely nominal subtyping relation might work, with all > the limitations that implies. > > Sandro > > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
