Domenic Denicola (2013-10-27T04:18:59.000Z)
Also http://www.slideshare.net/BrendanEich/js-resp/5, presented in convenient video form at http://www.youtube.com/watch?v=IXIkTrq3Rgg.

From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Rick Waldron
Sent: Sunday, October 27, 2013 00:06
To: Brandon Andrews
Cc: es-discuss at mozilla.org
Subject: Re: Proposal for new floating point and integer data types

Sorry for the top post, but I recommend reading this: http://wiki.ecmascript.org/doku.php?id=strawman:value_types

Rick

On Saturday, October 26, 2013, Brandon Andrews wrote:
I've seen posts asking for optional strong typing (often relating to typescript), but not many asking for data types. I think since the process takes a while it would be a good idea to consider adding extra data types on top of the already existing dynamic ones. I'll keep each comment short since everyone here is probably familiar with how Actionscript did their type specs. I'd like to discuss proposing these data types to start:

int,int8/16/32/64
uint,uint8/16/32/64
single (32-bit IEEE 754)
double (64-bit IEEE 754 as an alias for Number)

These correspond to most computer hardware and have fairly standard instruction set operations on them. The goal here is mostly to bring ECMAScript closer to a generic bit based computer. These types are fairly standard across hardware and are well understood in other languages.

var foo: uint16 = 100;
var bar: uint64 = foo;
var baz = bar >> 58;

This would in turn expand things that JavaScript was never able to do, which is to work with 64-bit types. (The idea being this could be expanded later for higher bit types).

This would translate to functions:
function Foo(a: int32, b: int32): int32
{
    return a + b;
}
var foo = new function(): void { }

Then expanding more, users would be allowed to type functions making function parameters easy to understand:

function Foo(a: function(a: int32, b: int32): int32): void
{
}

Other type specifications allowed would be bool, string, and object with the concept that classes would fit seamlessly into the typing when added later.

Some specific rules would be applied. Integer data types would not throw exceptions when overflowing keeping them simple. Any binary operation would immediately convert a single and double type to corresponding uint32 and uint64 data types.

The untyped Number data type would convert to any of the other types if possible. It would be up to the programmer to ensure a Number variable fits into the required data type.

var foo = 1000;
var bar: uint8 = foo; // 232

However a programmer could explicitly convert the type with the following syntax:

var foo = (10 * 100): uint8;

This proposal would also include changes to Array, Map, and Set with a generic type syntax found in C#:
var foo = new Array<int8>(100); // Identical to Int8Array
var foo = new Array<string, int8>();
var foo = new Map<int32,object>();
var foo = new Set<object>();
It would work as one would expect only accepting a specifically defined type.

int and uint would correspond to big integer data types which would remove any current limitation with integer based math. they would support syntax for typed array like views.
var foo: uint = 9999999999999999999999999999999999999;
var bar: Array<uint8> = foo;
var baz: uint8 = bar[0];

These views would also work with the non-big integer types. So:
var foo: uint32 = 42;
var bar: Array<uint16> = foo;
var baz: uint16 = foo[0];

They would also be the only way to go from an uint32/64 and int32/64 to a single or double like:

var foo: uint32 = 42;

var bar: single = (foo: Array<single>)[0];

While more verbose than other possible proposals it keeps with one syntax for all bitwise conversions.

The last edge case I'd like to cover is making the changes work with Math:

var foo: uint32 = 42;
var bar: single = Math.cos((foo * 42):double);

By default the return type would be inferred by the input type or storage type (in this case single) and the function would be overloaded for different inputs. As another example Math.min and Math.max would return their input data type rather than Number when the types are specified.

Benefits to this proposal would be easier optimization to map to hardware and operators. It would also help to alleviate the issues that caused the need for the TypeArray spec. That is allowing the user to work with types that map to native hardware on the CPU and GPU.

For developers who work with binary formats this simplifies the usage of integer and floats along with their respective binary operators.

The main issue I see is that big integers are niche so it might be a bit naive to include them, but it's something I'd prefer was included as it makes the language flexible for the future. The other issue is defining any type of generic syntax using <> would need serious discussion if there are any issues making the system compatible.

Future additions this would allow would be function overloading, but I left that out as it complicates the proposal.

I've been looking through the archive for similar discussions as I assume something like this has been proposed before. If anyone has any related links that would be appreciated along with a discussion of issues or compatibility conflicts. (Or general feelings toward adding types in general as ECMAscript has been fairly unchanged over the years with regards to types).
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org<javascript:;>
https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131027/b5e440ef/attachment.html>
domenic at domenicdenicola.com (2013-11-03T21:57:52.346Z)
Also http://www.slideshare.net/BrendanEich/js-resp/5, presented in convenient video form at http://www.youtube.com/watch?v=IXIkTrq3Rgg.