I'm not particularly enamored with inheritance, but wouldn't mind it as long as it solves the well-known problems with subclassing and subtyping [1]. Since you're looking at this from a CTS interoperability perspective, I suspect that isn't a viable goal, but I just thought I'd put it out there.
Sandro [1] http://okmij.org/ftp/Computation/Subtyping/ On 19/03/2010 6:12 PM, Jonathan S. Shapiro wrote: > I now think I can more or less see how to get single inheritance into > BitC. We won't infer it, because that wouldn't give a most general > typing, but I think we can handle it when it is user-specified. If we > introduce inheritance into the language, I believe that we should > continue to separate the definition of type from the definition of > implementation. In this view, a class definition is mainly seen as a > type class definition. > > Questions for the group: > > 1. How important is inheritance in the eyes of people here? > 2. Can anybody identify an "acceptable cost" strategy for transcoding > C++ to BitC without it? > 3. Can anybody identify a sensible way to interoperate effectively with > the Common Type System without single inheritance? > 4. Given that this can be deferred, how much impact does its presence or > absence likely to have on the early evolution of the BitC standard > library? Is that good or bad? > > To those of you coming at this from the Haskell and O'Caml (i.e. purely > functional) worlds, I'm particularly interested in your experience and > input, but a gentle reminder that BitC needs to be able to interoperate.... > > shap > > > > _______________________________________________ > 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
