Perhaps a good starting point would be a review of the reasons you're avoiding modern, lower-level existential constructs [1]. You can model interfaces and objects with such existentials, and they more closely match the low level semantics that BitC wants to achieve, ie. explicit control over storage, instead of implicit object layouts with vtables, etc.

Sandro

[1] "Modeling Abstract Types in Modules with Open Existential Types", http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.145.2787

On 27/10/2013 12:44 PM, Jonathan S. Shapiro wrote:
If the BitC work goes forward, one of the key decisions is whether to admit single inheritance into the language. There are a lot of pros and a lot of cons.

Originally, I chose to go procedural. This was partly because of the EROS/Coyotos experience. EROS was done in C++. The overheads were high. The complexity was high. Ultimately we had to compile with a lot of language features turned off, so it wasn't C++ anymore. It wasn't a good fit, since we (intentionally) didn't want inheritance or exceptions. So in Coyotos I switched back to C. The problem with C was that I really wanted a language with specified semantics. Thus BitC.

So we beavered away on BitC, and the time came to start writing the standard library. And for /that/ problem there sure seem to be a lot of cases where Interfaces (as opposed to TC instances) seem like a good match. And at least a few places where (single) inheritance seems like a really useful thing. Perhaps I let myself be discouraged too much by the problem with by-ref types not having been first class, and it all would have come out fine.

But if we're going to re-open this language, I think we need to come to a resolution on this. And I think it needs to have two parts: (1) a comparative discussion of interfaces and TC instances, and (2) a discussion of pros and cons for admitting objects.


shap


_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev

Reply via email to