Issues relating to 9.11 The SameValue Algorthm

Mark S. Miller erights at
Thu Nov 13 21:36:26 PST 2008

On Thu, Nov 13, 2008 at 5:38 PM, Allen Wirfs-Brock <
Allen.Wirfs-Brock at> wrote:

>  *From:* Mark S. Miller [mailto:erights at]
> >>I also think the SameValue name is misleading as it is really just a
> StricterEquality test and not a identical value test.  This name confusion
> is probably what caused it to be edited into [[DefineOwnPropety]].
> >As DavidSarah says, SameValue *is* an identical value test. The only
> difference between === and an identical value test is NaN and -0, which are
> therefore called out as special cases in SameValue.
> There is at least one case where it is not an identical value test.  That
> is the case where there are multiple implementation dependent NaN encoding
> as is explicitly allowed for by the specification. Even though == and ===
>  (and SameValue) does not distinguish them they are potentially
> distinguishable by a host object or otherwise using external code ad this
> distinction can be reported back to ECMAScrpt code.  As such, they don't
> meet my usual criteria as being identical values and in particular I would
> consider an apparent attempt to use Object.defineProperty to replace a
> readonly NaN value with a different NaN value encoding to be a violation of
> the [[Writable]]: false constraint.  That's why I don't believe it is
> appropriate to use SameValue in [[DefineOwnProperty]] .
> [...]
> As I've said above, I think observably different via calls to external code
> is enough to call into question the sameness of two values. This is
> particularly the case when we are dealing with primitive data types  like
> binary and decimal floats that routinely flow across language or other
> domain boundaries. I'm not particularly concern about language specific
> types and values (for example, a language specific closure type) that is
> unlikely to be passed or have meaning across such boundaries. Obviously, an
> implementation should be free use alternative encoding for the "same" value
> but it probably needs to cannonicalize such representations when passing
> them outside its private implementation domain. Unless we require
> canonicalization for primitive values on calls to/from host objects we
> probably need to be a little less parochial about what is observable.

Well, I'm glad at least to see realization of the significance of this
issue, although I arrive at a different conclusion. In ES itself (ignoring
decimal for now), there really is only one NaN value. If a call to
[[DefineOwnProperty]] may be rejected because a presented NaN was not
identical enough to a stored NaN, even though they do not differ in any way
detectable or explicable to a JavaScript programmer, then we may as well
instead specify that [[DefineOwnProperty]] just randomly succeeds or fails
at the implementation's whim.

I do not think it is productive to imagine that we can evade our
responsibility as language designers to say what the potentially
distinguishable values are in our semantic state. No such decision will be
satisfying. Any decision will have unfortunate consequences. But not
deciding is worse.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Es-discuss mailing list