On Fri, Mar 23, 2012 at 8:52 PM, wren ng thornton <[email protected]> wrote:
> But maybe we can learn enough to make a better go of it next time. (For > example, I don't entirely follow why you now think subtyping is requisite.) > > I think we can, and I plan to send out another note (perhaps even tonight) going into more detail on why type classes did net work for us as we hoped. For now, let me try to answer your question about subtyping. For region types, the answer should be clear: stack regions have a containment relation that is naturally described by subtypes. It is also useful for regions to be polymorphic. When both features (subtyping and polymorphism) you've more or less committed yourself. For datatypes, there are two answers: 1. Pragmatic: we need a way to transcode C++ code without re-architecting at the same time. 2. Requirements: the is-kind-of relationship turns out to be pervasive in system code. Concerning point (1), it isn't enough (at least in my opinion) to generate a language that is a better alternative to C++. We also need a language into which we can transcode a relatively short list of key libraries that are presently implemented in C++. We really don't want to have to re-factor or re-architect those libraries at the same time we transcode them. Why not just use them as "foreign" libraries? Mainly because of (a) the imprecise GC problem and (b) the fact that many of these libraries are safety critical or security critical (e.g. OpenSSL). So that's the purely pragmatic view, but I think it's sufficient. Concerning the is-kind-of relation, my original intention had been to refactor that sort of thing into interfaces captured by type classes - which would have worked for the Coyotos kernel. Unfortunately, that approach only works practically if whole-program compilation is assumed. In particular, it doesn't work at all across library boundaries, and I think that's essential. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
