Loose type checking in E
Mark S. Miller
Mon, 12 Oct 1998 10:17:55 -0700
[Originally sent to Tyler. Forwarded with permission. --MarkM]
At 06:36 PM 10/2/98 -0400, Tyler Close wrote:
>We met a couple of weeks ago at a Foresight meeting. I was there with Ping.
>I was just thinking about my gripe about no static type checking in E. It
>occurs to me now that the runtime checks on method name / # parameters
>enables parameratized programming of the kind that C++ templates allow,
>without causing the source code explosion that C++ templates create.
>You've no doubt already thought of this, but it would be a good thing to
>mention the next time some smart ass complains about no static type
>checking. It certainly would've shut me up.
While I would like to use this rationale, it doesn't quite work. Other
languages with parametric polymorphism (ie, like C++ templates) include
Eiffel, ML, and the Pizza variant of Java. All of these consider a
parameterization of a parameterized type to be equivalent to an expansion
with these type parameters filled in, but in the other languages, rarely
does the implementation need to actually do any expansion. Usually they can
all share one implementation, with the parameterized type checking being
only a static theory *about* what the run-time situation means. C++ painted
itself into many corners (like argument-type-based overload resolution),
some of which obligated it to usually expand parameterized types in the
In any case, our conversation and your discomfort were very useful to me.
At http://crit.org/http://erights.org/doc/elang/elangmanual.pdf you'll find
the latest definition of Kernel E, including the "definer" pattern
(currently on page 16) that emerged from that discussion. There's still no
static type *checking*, but I now have optional type declarations. These
declarations provide enough info to enable the simple compiler I have in
mind to usually generate efficient code, and a static type checker could be
built as a separately runnable lint-like tool.
>I am also still a little hung up on your process style concurrency scheme.
>Can one vat make a series of method calls on another vat in an atomic
>fashion? If so, how?
No. Between vats we only have asynchronous sends. Otherwise E wouldn't be
>I remember that one of the reasons for abandoning multi-threading was to
>eliminate wall-banging; however, if you made thread creation a capability,
>with a ThreadMaker object, wouldn't you still be able to guarantee
>deterministic execution of untrusted code and thus eliminate wall-banging?
Yes, but wall-banging is not the main reason for giving up multi-threading.
The main reason is that -- despite the acceptance of multi-threading by the
entire industry -- for general purpose programming, it is an unworkable
concurrency control paradigm. (The multi-threading paradigm can be the
right thing for certain special cases, but it's ok with me if these cases
are uncodable in E.)
Correctness requires both that we maintain consistency and that we avoid
deadlock. Within the threading paradigm, "thread-safe" programming requires
locking on many individual "thread-safe" abstractions/data-structures. By
the time we've put enough fine-grained locks in to preserve consistency, we
can no longer document the composition rules needed to avoid deadlock. A
good example is Javasoft's attempts at a GUI library (the AWTs and Swing) vs
the EC Habitats Beta.
Javasoft is firmly in the multi-threaded paradigm, and has tried through
four generations to build a multi-threaded GUI library (Oak AWT, Java 1.0x
AWT, Java 1.1x AWT, Swing). Over time, these have gradually migrated away
from actually *using* multi-threading and towards event-loops, but without
ever giving up on multi-threading. Even Swing's documentation admits that
it suffers from *both* race condition and deadlock bugs, without providing
adequate guidance for avoiding these bugs.
In contrast, the EC Habitats Beta, though put together sloppily and in a
hurry, and only living through *one* customer release cycle, had essentially
no race condition or deadlock bugs, despite taking on vastly harder
concurrency problems than any faced by Javasoft (after all, it was a
symmetric distributed system). I attribute this to the
asynchronously-coupled event-loop paradigm, which is really the Actor
paradigm in different clothing.
>I really enjoyed the meeting and learning about E. The more I think about
>it, the more slick it seems.
>I would very much appreciate being put on the
>ad hoc mailing list you have for E.
Will do. May I forward our correspondence to the list?