value_types + struct+types = decimal

Brendan Eich brendan at
Mon Oct 18 15:57:24 PDT 2010

On Oct 18, 2010, at 3:16 PM, Sam Ruby wrote:

> On Mon, Oct 18, 2010 at 6:01 PM, David Herman <dherman at> wrote:
>> Are you suggesting a) that struct types should always be value types, or b) some sort of extension to the binary data spec that allows the creation of immutable structs that are value types?
>> I'm afraid a) just seems unworkable -- compound binary data needs to be mutable, and its sub-components really need to be selectable by reference, not by copying. If you meant b) (or something else), can you flesh it out a bit more?
> Another possibility is that the current proposal labeled "value-types"
> doesn't mention immutability :-)

It does, spelled "frozen": see

  Value Type means “shallow frozen”.
 and look for other "frozen" matches in

> That being said, if the immutability is a pre-requisite for
> "value-types" (presumably in order to address the triple equals hard
> case), and given that value-types was tossed out there as a potential
> solution to the bignum requirement, can somebody sketch out how ===
> would work for bignums?  My intuition is that any triple-equals
> solution that works for bignums would also work for decimal.

No intuition needed, the page was explicit in paraphrasing Mark's position:

 ...  Mark: no, Value Types mean === can do a recursive, cycle-tolerant structural comparison. Jason: not convinced that complexity is warranted.

On es-discuss in the "Structs" thread, Waldemar wrote at the following:

> b = a[i];
> a[i].x += 1;
 . . .
> That leads to a couple plausible meanings of b === a[i]:
> 1.  Pointer equality:  True if and only if mutating one's contents would mutate the other's.
> 2.  Recursive value equality:  True if and only if all of their constituent elements are ===.  I hope that you can't have things like aliases themselves as first-class values inside structs, as that could create cycles (although you could still make === work in that case if you really wanted to).
> Bit-by-bit equality is not desirable in the presence of NaN's and signed zeroes.  If we go with choice 2, the struct {x:17, y:NaN} should not be === to {x:17, y:NaN}.  Using bit equality, it might or might not be ===, which then could be used to discriminate among different kinds of NaN's.  There is currently nothing in the language with that power and I'd prefer to keep it that way.

But of course the context here includes mutability, since we were talking about WebGL typed arrays, in the same vein as Dave's strawman. Mutability is a requirement but === is not.

If we separate value types from binary data, where operators including === are required for value types such as bignums, decimal, etc., then we could choose to make value types deeply frozen, and define === as Mark proposed. But Waldemar objected to this because it fails to equate -0 and 0, and it does equate NaN.

Still, I believe separating binary data from value types is the right choice. You could use frozen binary data to implement the representation of a value type, whose operators and literal syntax would come from its object-like "clothing" (whether declarative via new syntax or using some Proxy-like API, details TBD).

And I believe making value types frozen in some sense is important, for preservation of === and other invariants, and for memoization and sharing of value type instances created via literals.


More information about the es-discuss mailing list