Well-supported arrays of structs (as schemas) might be a
satisfactory
compromise. Consensus emerging around that solution.
Structs in ECMA-334 are value types, and consist of members that
also
are value types. Would structs in future revisions of ECMA-262 share
these characteristics?
Is it fair to assume that there would end up being a more richer set
of primitives to select from when composing a struct than simply
"object", "boolean", "number", "string" and the like? Again,
ECMA-334
defines the following:
Would something similar be envisioned for ECMA-262?
No, we did not envision adding more primitive types, type
annotations,
conversion rules, and first-class struct declarations.
Something more like
const TA =
Array.newTypedArray(fixed_length,
Object.newStructType({x:"u32", y:"u32", z:"u32",
r:"u8", g:"u8", b:"u8", a:"u8"}));
let a = new TA(...);
... a[i].x ...
I'll note that with newStructType one could define a 128 bit
quantity for representing a complex number. That coupled with
something like the following proposal would enable a complete set of
complex arithmetic operators to be supported:
Value types are the whole of the work left to write up as a strawman,
never mind structs, once we swallow the brute-force solution for
operator dispatch: double dispatch for dyadic operators.
The objection to double dispatch is that you can't have a third party,
Carol, take Alice's Rational and Bob's Complex, and make Ratplex with
its own operators that handle arbitrary combinations of Rational and
Complex. You have to wrap Rational and Complex, or hack on their
sources, or otherwise monkey-patch.
Multimethods (dynamic typing only, of course) would avoid this, but
they are a complex new dispatch mechanism, not something I can justify
adding to JS.
So, let's say double dispatch is the way to go. Structs as sketched in
this thread help, but you really don't need them. You could use short,
fixed-length, dense arrays of uint32 values and modern implementations
will (soon, or already) optimize well. And you may not need 128 bits
contiguous dense storage: Complex would want a pair of doubles, at
first glance.
So I'm not sure we want to couple the low-level, machine-type
oriented, packed "struct schemas" (or whatever the argument or result
of Object.newStructType might be called) with value types.
Anyway, having a value types proposal that composes well with any
"struct and struct array schema" proposal would be great. We want
orthogonal, compositional primitives where possible, with usability
helpers (and independent, pure usability fixes) as needed. The major
issues confronting value types are
Usability requires operator syntax, but dispatched how? Double
dispatch seems the only reasonable way.
Lexical extension for literals, detailed proposal still needed.
On May 27, 2010, at 1:10 PM, Sam Ruby wrote:
> On 05/27/2010 03:05 PM, Brendan Eich wrote:
>> On May 27, 2010, at 11:38 AM, Sam Ruby wrote:
>>
>>>> Well-supported arrays of structs (as schemas) might be a
>>>> satisfactory
>>>> compromise. Consensus emerging around that solution.
>>>
>>> Structs in ECMA-334 are value types, and consist of members that
>>> also
>>> are value types. Would structs in future revisions of ECMA-262 share
>>> these characteristics?
>>>
>>> Is it fair to assume that there would end up being a more richer set
>>> of primitives to select from when composing a struct than simply
>>> "object", "boolean", "number", "string" and the like? Again,
>>> ECMA-334
>>> defines the following:
>>>
>>> http://en.csharp-online.net/ECMA-334:_11.1.5_Integral_types
>>>
>>> Would something similar be envisioned for ECMA-262?
>>
>> No, we did not envision adding more primitive types, type
>> annotations,
>> conversion rules, and first-class struct declarations.
>>
>> Something more like
>>
>> const TA =
>> Array.newTypedArray(fixed_length,
>> Object.newStructType({x:"u32", y:"u32", z:"u32",
>> r:"u8", g:"u8", b:"u8", a:"u8"}));
>> let a = new TA(...);
>>
>> ... a[i].x ...
>
> I'll note that with newStructType one could define a 128 bit
> quantity for representing a complex number. That coupled with
> something like the following proposal would enable a complete set of
> complex arithmetic operators to be supported:
>
> https://mail.mozilla.org/pipermail/es-discuss/2009-January/008535.html
Yes, but the "coupled with" is the whole point of
http://wiki.ecmascript.org/doku.php?id=strawman:value_types
See the early link to jorendorff's post on this list:
https://mail.mozilla.org/pipermail/es-discuss/2009-October/010068.html
Value types are the whole of the work left to write up as a strawman,
never mind structs, once we swallow the brute-force solution for
operator dispatch: double dispatch for dyadic operators.
The objection to double dispatch is that you can't have a third party,
Carol, take Alice's Rational and Bob's Complex, and make Ratplex with
its own operators that handle arbitrary combinations of Rational and
Complex. You have to wrap Rational and Complex, or hack on their
sources, or otherwise monkey-patch.
Multimethods (dynamic typing only, of course) would avoid this, but
they are a complex new dispatch mechanism, not something I can justify
adding to JS.
So, let's say double dispatch is the way to go. Structs as sketched in
this thread help, but you really don't need them. You could use short,
fixed-length, dense arrays of uint32 values and modern implementations
will (soon, or already) optimize well. And you may not need 128 bits
contiguous dense storage: Complex would want a pair of doubles, at
first glance.
So I'm not sure we want to couple the low-level, machine-type
oriented, packed "struct schemas" (or whatever the argument or result
of Object.newStructType might be called) with value types.
Anyway, having a value types proposal that composes well with any
"struct and struct array schema" proposal would be great. We want
orthogonal, compositional primitives where possible, with usability
helpers (and independent, pure usability fixes) as needed. The major
issues confronting value types are
1. Usability requires operator syntax, but dispatched how? Double
dispatch seems the only reasonable way.
2. Lexical extension for literals, detailed proposal still needed.
3. The big one: is it all worth it? I continue to think so, for
reasons adduced at http://jroller.com/cpurdy/entry/the_seven_habits_of_highly1
(funny).
/be
On May 27, 2010, at 1:10 PM, Sam Ruby wrote:
Yes, but the "coupled with" is the whole point of
strawman:value_types
See the early link to jorendorff's post on this list:
esdiscuss/2009-October/010068
Value types are the whole of the work left to write up as a strawman,
never mind structs, once we swallow the brute-force solution for
operator dispatch: double dispatch for dyadic operators.
The objection to double dispatch is that you can't have a third party,
Carol, take Alice's Rational and Bob's Complex, and make Ratplex with
its own operators that handle arbitrary combinations of Rational and
Complex. You have to wrap Rational and Complex, or hack on their
sources, or otherwise monkey-patch.
Multimethods (dynamic typing only, of course) would avoid this, but
they are a complex new dispatch mechanism, not something I can justify
adding to JS.
So, let's say double dispatch is the way to go. Structs as sketched in
this thread help, but you really don't need them. You could use short,
fixed-length, dense arrays of uint32 values and modern implementations
will (soon, or already) optimize well. And you may not need 128 bits
contiguous dense storage: Complex would want a pair of doubles, at
first glance.
So I'm not sure we want to couple the low-level, machine-type
oriented, packed "struct schemas" (or whatever the argument or result
of Object.newStructType might be called) with value types.
Anyway, having a value types proposal that composes well with any
"struct and struct array schema" proposal would be great. We want
orthogonal, compositional primitives where possible, with usability
helpers (and independent, pure usability fixes) as needed. The major
issues confronting value types are
dispatch seems the only reasonable way.
reasons adduced at jroller.com/cpurdy/entry/the_seven_habits_of_highly1 (funny).
On May 27, 2010, at 1:10 PM, Sam Ruby wrote: > On 05/27/2010 03:05 PM, Brendan Eich wrote: >> On May 27, 2010, at 11:38 AM, Sam Ruby wrote: >> >>>> Well-supported arrays of structs (as schemas) might be a >>>> satisfactory >>>> compromise. Consensus emerging around that solution. >>> >>> Structs in ECMA-334 are value types, and consist of members that >>> also >>> are value types. Would structs in future revisions of ECMA-262 share >>> these characteristics? >>> >>> Is it fair to assume that there would end up being a more richer set >>> of primitives to select from when composing a struct than simply >>> "object", "boolean", "number", "string" and the like? Again, >>> ECMA-334 >>> defines the following: >>> >>> http://en.csharp-online.net/ECMA-334:_11.1.5_Integral_types >>> >>> Would something similar be envisioned for ECMA-262? >> >> No, we did not envision adding more primitive types, type >> annotations, >> conversion rules, and first-class struct declarations. >> >> Something more like >> >> const TA = >> Array.newTypedArray(fixed_length, >> Object.newStructType({x:"u32", y:"u32", z:"u32", >> r:"u8", g:"u8", b:"u8", a:"u8"})); >> let a = new TA(...); >> >> ... a[i].x ... > > I'll note that with newStructType one could define a 128 bit > quantity for representing a complex number. That coupled with > something like the following proposal would enable a complete set of > complex arithmetic operators to be supported: > > https://mail.mozilla.org/pipermail/es-discuss/2009-January/008535.html Yes, but the "coupled with" is the whole point of http://wiki.ecmascript.org/doku.php?id=strawman:value_types See the early link to jorendorff's post on this list: https://mail.mozilla.org/pipermail/es-discuss/2009-October/010068.html Value types are the whole of the work left to write up as a strawman, never mind structs, once we swallow the brute-force solution for operator dispatch: double dispatch for dyadic operators. The objection to double dispatch is that you can't have a third party, Carol, take Alice's Rational and Bob's Complex, and make Ratplex with its own operators that handle arbitrary combinations of Rational and Complex. You have to wrap Rational and Complex, or hack on their sources, or otherwise monkey-patch. Multimethods (dynamic typing only, of course) would avoid this, but they are a complex new dispatch mechanism, not something I can justify adding to JS. So, let's say double dispatch is the way to go. Structs as sketched in this thread help, but you really don't need them. You could use short, fixed-length, dense arrays of uint32 values and modern implementations will (soon, or already) optimize well. And you may not need 128 bits contiguous dense storage: Complex would want a pair of doubles, at first glance. So I'm not sure we want to couple the low-level, machine-type oriented, packed "struct schemas" (or whatever the argument or result of Object.newStructType might be called) with value types. Anyway, having a value types proposal that composes well with any "struct and struct array schema" proposal would be great. We want orthogonal, compositional primitives where possible, with usability helpers (and independent, pure usability fixes) as needed. The major issues confronting value types are 1. Usability requires operator syntax, but dispatched how? Double dispatch seems the only reasonable way. 2. Lexical extension for literals, detailed proposal still needed. 3. The big one: is it all worth it? I continue to think so, for reasons adduced at http://jroller.com/cpurdy/entry/the_seven_habits_of_highly1 (funny). /be