On Thu, Mar 11, 2010 at 9:23 AM, Aleksi Nurmi <[email protected]> wrote: > "Something we didn't want was an object-oriented language. OO > languages remain a popular fad, but our experience using C++ in the > EROS system was that it actively got in the way of understanding what > was going on. We also think it's a bad sign that the C++ language > evolution has adopted a policy of "extension by ad hoc complexity.'""
Back when I wrote that, BitC was primarily a research compiler. One of the less fortunate attributes of academic research is that success requires you to focus on narrow problems with clearly defined, replicatable objectives. Two examples: - In EROS and Coyotos, we took the public position that capabilities were the Right Thing and identity-based controls should be thrown away. In real-world systems this is abject nonsense, but it was necessary to push the capability idea to its extremes in order to re-establish its validity. If we had done that in a hybridized way, people would have continued to believe that capability systems were not viable. - In BitC, we needed to focus on a well-defined problem, and in particular, on problems that could be captured through type. This, of course, is necessary but not sufficient for a production language. In particular, the research publication requirement for sound and complete inference giving principal typings is not a requirement for a production compiler. Sound yes, complete no, principal typings no, explainable when completeness and principality are not achieved yes. As you can see from the note I just posted about a possible way to handle inheritance, it doesn't actually look like inheritance demands much more than we already have. We have a qualitatively similar ordered-union-like mechanism in our resolution strategy for integral types. So if what it takes for us to support inheritance turns out to be as simple (ha!) as what I outlined, or something close to that, then I think it's politically advisable to do it. One thing that makes me think this might be okay is that the strategy I proposed once again dodges the subtyping bullet, which was one of the things we were concerned about in OO support. > But creating a "BitC/CLI" superset for interop purposes would be > great, of course. But there are a lot more to the CTS than objects. Certainly true. What else comes to mind that doesn't map straightforwardly into BitC? The main thing I see at this point is method overload resolution. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
