[bitc-dev] Retrospective Thoughts on BitC
Jonathan S. Shapiro
shap at eros-os.org
Sat Mar 24 16:03:09 PDT 2012
On Fri, Mar 23, 2012 at 8:52 PM, wren ng thornton <wren at freegeek.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitc-dev