[E-Lang] Reliance & Static Security Checking

[Bill Frantz]

At 09:05 PM 1/4/01 -0800, Mark S. Miller wrote:
>1) Syntax.  Here it is with syntax corrected:

Oh well, I knew I should have tried to run it.


>2) Hashing and hash tables are hidden inside the E implementation / UTCB.  
>Hash values are not exposed, and hash tables are therefore a primitive type 
>in E -- the various kinds of Maps.  This hides the non-determinism that 
>EQ-based-hash-values would expose, and it allows E's Maps to avoid relying
on 
>their clients -- the correctness of an E Map is not vulnerable to the 
>objects stored in the map.

I just spent some time with the E Map documentation trying to decide if
they used (in the Java syntax == or a.equals(b)).  The clever answer is, it
depends.  It depends on whether the objects are selfless or not.

While for most uses, you may be happy with the E definition of ==, for some
uses you may well want to build hash tables on a.equals(b).  A poor example
is an RSA private key.  RSA private keys can either consist of {n, d} where
n is the product of two primes (p, q), and d is the secret value; or {n, d,
and some other values which speed up the calculations}.  I can imagine
wanting to define an RSA key with the speed-up values as being equal to one
without for hash table key purposes.  (RSA private keys would probably be
defined as selfless objects, so they would be pass-by-copy.)


>> This makes the
>>rely/suspect pair very much like the /*null OK*/ comment convention adopted
>>by Java programmers to document whether a parameter/return value could be
>>null. 
>
>Actually, the /*null OK*/ style started in the Xanadu days, probably from 
>Dean, Ravi Pandya, Eric Hill, or myself.  It was translated from Smalltalk
and 
>C++ into Java and Original-E at Agorics and Electric Communities.

Thanks - I didn't know the history.