On 05/27/2010 08:36 PM, Brendan Eich wrote:
On May 27, 2010, at 5:21 PM, Sam Ruby wrote:
a[0] = a[1] could also be made to work with sealed objects reflecting
the struct elements of the arrays. The right-hand side reifies or finds
the memoized object reflecting a[1], the packed struct. The assignment
to a[0] then reads property values from the object (fat ugly numbers!)
and writes into the packed struct at a[0] according to the schema.
... and the value of a[0] === a[1] is?
With any kind of mutable object reflecting the packed struct, the answer
will be false unless we have value types. See
http://wiki.ecmascript.org/doku.php?id=strawman:value_types#hard_cases
search for ===.
And I previously argued that false would be unexpected, that's how I
came to the conclusion that structs in ECMA 262, just like in ECMA 334,
should be value types.
Value types were conceived of as shallowly frozen, but we could try to
relax that.
So it still seems to me one could avoid equating value types and these
schema structs. They are distinct proposals, but you could tie them
together. I think that would be a mistake at this point, especially
since WebGL folks have no need for operators and literals (as far as I
know).
It is not a matter of whether they "need" === operators to be defined,
but rather a matter of defining what the value of === operators is to be.
Nor, am I suggesting that === be overloadable.
I am suggesting that if a[0]===a[1] is to be true, and one can assume
that a[n] is a series of octets, then we are talking about strncmp
like behavior. And if we can assume strncmp, then I see no reason to
preclude implementations from using strncpy.
If you want this, whether === is overloadable, and WebGL (lots of folks,
let's say) want structs in the array to be mutable, then we run into the
conflict recorded in the wiki.
''Jason: === must be overloadable. Mark: no, Value Types mean === can do
a recursive, cycle-tolerant structural comparison. Jason: not convinced
that complexity is warranted.
...
Decision logic:
if (=== is overloadable) {
The need for egal goes up;
if (egal is added (it is not overloadable))
{0, -0} and NaN issues go away;
} else {
The need for egal goes down,
because === is well-defined as structural recursive etc. comparison;
}
Value Type means “shallow frozen”.''
Say we add egal, so one can tell the difference between a[0] and a[1]
even if they happen to contain the same bits, because that difference
might matter due to one of them being mutated to have different bits.
I don't follow that.
If a[0] and a[1] have the same bits, why would a[0] === a[1] ever be false?
Then do the objections to unfrozen value types go away? Cc'ing Mark.
I am not assuming that === be overloadable. Nor am I presuming that
value types are mutable.
Some people believe that the {0, -0} and NaN behaviors are a historical
wart, to be avoided in all future work. Others believe that consistency
here is important. I see merit in both sides, and in any case believe
that the issue can be made to go away without requiring an egal method.
At most, all that is requires is the addition of methods to determine
NaN-ness and Zero-ness.
Pseudo-code:
function "==="(a,b) {
if (strcmp(a,b)) {
return a.isZero() && b.isZero();
} else {
return !a.isNaN()
}
}
My assumptions are that "overloading" the operators for value types, at
some point in time, and based on double-dispatch approach, will be seen
as a good idea as a possible candidate for inclusion in some version of
ECMAScript. Furthermore, I am assuming that whatever is designed for
value types should apply to structs -- unless there is a compelling
reason not to. As you put it: 'having a value types proposal that
composes well with any "struct and struct array schema" proposal would
be great.'
What I see in structs is the potential to define a 128 bit quantity that
could be efficiently schlepped around. I don't see a need to modify one
-- instead if you want a new value, you create one. But I don't believe
that the end result of "a=b" should result in a situation where "a !==
b' for structs any more than it does today for either Numerics today or
for Objects (with the one notable exception being NaN... meh).
Further, I see in structs as a data type with no legacy. And one where
neither arithmetic nor comparison functions are super-duper-ultra
performance critical. By that I mean that the isZero and isNaN calls
above are tolerable.
A combination of double-dispatch and existing ES objects could enable
the creation of an infinite precision integer library -- written in pure ES.
A combination of double-dispatch and structs could enable the creation
of 128 bit decimal objects. Again, this could be written in pure ES.
Should it prove popular, vendors may chose to optimize this, and perhaps
even standardize the library.
Or not. In fact, there need not be only one true decimal library. If
others have different ideas on how decimal should be implemented, they
would be free to create their own.
/be
- Sam Ruby
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
