Loose type checking in E

[Mark S. Miller]

[Originally sent to Tyler.  Forwarded with permission.  --MarkM]


At 06:36 PM 10/2/98 -0400, Tyler Close wrote:
>Hi Mark,
>
>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 
implementation.

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 
deadlock-free.


>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. 

Thanks much!


>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?

	Cheers,
	--MarkM