Proposal for new floating point and integer data types

Rick Waldron waldron.rick at gmail.com
Sat Oct 26 21:06:01 PDT 2013


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/d5885584/attachment-0001.html>


More information about the es-discuss mailing list