Announcing E 0.8.4: The Birthday Release

[Dean Tribble]

>The real "==" has now mostly arrived.  E's "==" (like Java's, PPSmalltalk's, 
>and Squeak's "==", Python's "is", and Lisp's "EQ"), is a primitive that 
>can't be overridden by user code.  It does not work by sending any messages. 
>When it says "x == y", this really means x and y are indistinguishable in 
>their effects on future computation.  The Grant Matcher Puzzle 
>http://www.erights.org/elib/capability/grant-matcher/index.html explains why 
>such a primitive is necessary to combine trust from separately 
>partially-trusted sources.

I trust (or at least hope) that the ability to engage in this
abstraction-breaking event is a capability such that it can be virtualized
given the appropriate sacrifices to the lords of chaos.

>All this cycle handling may seem complicated when you try to think about it, 
...
Note that in general, many of these classes of issues are complicated when
you actually *think* about them.  That is partly so that using them is not
complicated (or bug-prone).

>If == is asked before there is enough information to give a stable answer, 
>rather than give an unstable answer, == throws and exception.  Since it does 
>not always give an answer, it is "partial" rather than total.  Since the 
>cases for which it does give an answer only grows over time, and since the 
>answers it does give are stable, it is "monotonic".  (This resembles 
>read-only-unification, or ask-unification, in the Concurrent Prolog family 
>of languages.)

Except that they block rather than abort when the value hasn't been
established.  How much pain is the differences going to cause?  I presume
the semantics are such that you can't force a wait for resolution when ==
is used?

>finite.  Only settled objects can be used as keys in EMaps.  I suspect that 
>after talking to Arturo, we'll also want to say that only settled data can 
>be made persistent.

?!  That seems a dire reduction in functionality.  Is it?

>A long time ago, I had noticed the threat to determinism posed by 
>Object.hashCode() or any equivalent, and these are not accessible in E.  As 
>a result, E's hashtables are necessarily primitive -- one cannot implement a 
>new hashtable in E. This seems a small price.  However, not until after the 

Why don't you instead allocate a deterministic hash in each
identity-object.  Then hashtables can be implemented in the language.
Since many clever algorithms and distributed coordination things might want
to use hash, that seems perhaps a better tradeoff.  note that of course you
don't have to allocate the hash until it is used.

>There's no good answer to this problem, but the least bad answer seems to be 

How expensive is it to guarantee these semantics?  

I'm glad to see integrated support for sorting.  That turns out to be very
important when moving from small examples to real applications.

>With these two properties, hashtable order becomes useful for other things, 
>and not just something we have to preserve for the sake of determinism.  

It certainly makes regression testing much better!  (Though in fact writing
out sorted results is more reliable.)