value_types + struct+types = decimal
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?
On Mon, Oct 18, 2010 at 6:01 PM, David Herman <dherman at mozilla.com> 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 :-)
My read of the so-called value-types proposal is that some (as of yet undefined) mechanism which will cause some set of non-primitive objects to override the default "call toString() and concatenate the results" behavior for the plus operator. That override would likely be some form of double-dispatch.
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.
Dave
- Sam Ruby
On Oct 18, 2010, at 3:16 PM, Sam Ruby wrote:
On Mon, Oct 18, 2010 at 6:01 PM, David Herman <dherman at mozilla.com> 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 strawman:value_types.
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 esdiscuss/2010-June/011316 the following:
b = a[i]; a[i].x += 1; . . . That leads to a couple plausible meanings of b === a[i]:
Pointer equality: True if and only if mutating one's contents would mutate the other's.
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:binary_data 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.
On Mon, Oct 18, 2010 at 6:57 PM, Brendan Eich <brendan at mozilla.com> wrote:
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).
Any reason to believe that would necessarily incur significant performance overhead? If not, that's fine with me.
- Sam Ruby
I wrote up a design a while back for what might be called "value proxies", which extend the Javascript proxy proposal to also trap primitive operators, enabling libraries for bignums or decimals, etc. The write-up is for an idealized 'micro-Javascript' language, but still helps clarify parts of the potential design space.
I just want to mention that this is an awesome paper. And I like its approach to introducing operator overloading into the language.
I'm pleased to see value_types discussed again:
brendaneich.com/2010/10/should-js-have-bignums
It is my belief that value_types[1] and struct_types[2] are sufficient to build a pure ECMAScript implementation of Decimal. Such an approach would solve a number of problems:
(1) Ubiquity. Making Decimals a required feature was controversial within the committee. Anything less would hamper adoption. Making the implementation in ECMAScript and having that implementation only depend on value_types and struct_types, then the implementation effectively becomes as ubiquitous as those two features.
(2) Format. A number of committee members objected to 754R as a format. Those that wish to pursue their own formats would be welcome do to so.
The only key requirement that this is not known to satisfy is:
(3) Performance. While we were not expecting hardware level performance, something approximating C-level performance was the goal.
Mitigating that is:
(3a) ECMAScript implementations have improved dramatically since this was last evaluated. The expectation is that this trend will continue. And given the expected use case for struct_types, it is especially likely that that feature will be implemented with performance in mind.
(3b) Not all users have the same performance requirements.
(3c) A stable implementation written in C with a liberal license[3] continues to be available. This will always be an option for enlightened browser vendors with an interest in performance.
Given those mitigating factors, I am quite willing to proceed with the above approach, and would strongly encourage the committee to consider adopting the value_types proposal, and to not make any design decision which would preclude struct_types from being considered as a value_type.
[1] strawman:value_types [2] strawman:binary_data#structs [3] download.icu-project.org/files/decNumber/decNumber-icu-368.zip