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