warcraftthreeft at sbcglobal.net (2014-11-24T17:15:57.140Z)
Took a break while I worked on some Javascript projects for the past year to see if they'd give me more perspective on types. I'll keep this short though.
Brendan Eich wrote:
> No one is proposing type annotations a la ES4 or TypeScript, note well.
I'm thinking the discussion needs to start up again for the sake of JS's future. Basically building a base for other languages and also making JS a more complete language by itself. Before I get into that though I have a few comments and questions.
Starting with this video from Brendan Eich that was linked: https://www.youtube.com/watch?v=IXIkTrq3Rgg
Regarding Literal Syntax ( http://www.slideshare.net/BrendanEich/js-resp/14 ) used in other languages I think Javascript could handle it cleaner without arbitrary suffixes like L, UL, f, n, and m. I'm not totally against the idea, but would constructors always work as an alternative? bignum(1234567890). If so it seems fine. (I just want to make sure the literal syntax is optional for all proposed types).
The proposed operator overloading syntax ( http://www.slideshare.net/BrendanEich/js-resp/15 ) has the right idea, but I think partial classes might be a cleaner approach. Basically being able to define the same class multiple times and having their implementations merged ignoring duplicates.
```js
value class vector2d
{
x: float32;
y: float32;
get Length():float32
{
return Math.sqrt(x * x + y * y); // uses Math.sqrt(v:float32):float32 due to input and return type
}
constructor(x:float32 = 0, y:float32 = 0)
{
this.x = x;
this.y = y;
}
operator +(v:vector2d)
{
return vector2d(this.x + v.x, this.y + v.y); // return value type
}
operator ==(v:vector2d)
{
// equality check between this and v
}
}
```
```js
// In MyClass.js defined extensions to vector2d
class vector2d
{
operator ==(v:MyClass)
{
// equality check between this and MyClass
}
}
```
The implementation would then just need to update the current class definition as Javascript files are loaded. The other advantage with this is it allows for organization of operators which can be convenient for math objects that are required to work with many objects or third party code.
For value type classes are they always passed by reference? I didn't see anything regarding pass by reference syntax. Do value classes have a copy constructor or something for cloning objects in that case?
Okay onto typing. Ultimately what I'd like to happen is for an ECMA member to understand the value of static typing for JS and help turn this into a rough draft proposal that can be expanded on with critiques.
What I keep seeing from years of conversation are comments like in this thread: https://esdiscuss.org/topic/optional-argument-types
Brendan Eich wrote:
> Types are hard. This doesn't mean "no, never". But big brains are still researching the general topic, and btw what Dart has can't be called types according to the researchers and literature I trust.
There's not even a proposal for people to begin discussing the grammar and implications on JS though. It was given mild interest years ago, but it's past the time for putting off the discussion. (Also it doesn't look like anyone is against adding this. I've read a large part of the mailing list so far which discusses typing a lot).
So what a static typing proposal should have at the minimal are the following types (lowercase seems to look best I think):
```js
bool
string
uint8/16/32/64
int8/16/32/64
float32/64
bignum
decimal
int32x4, int32x8
uint32x4, uint32x8
float32x4, float32x8
```
I saw the following mentioned in Brendan's slides and they'd probably be nice if a standardized interface and implementation is found:
```js
rational
complex
```
The ability to type any variable including lambdas. I'd go with the already proposed syntax that's been around for years. I've read the old guard and trademarks type proposals, but they seem unneeded for now.
```js
var foo:uint8 = 0;
var foo = uint8(0); // cast
var foo:(int32, string):string; // hold reference to a signature of this type
var foo = (s:string, x:int32) => s + x; // implicit return type of string
var foo = (x:uint8, y:uint8):uint16 => x + y; // explicit return type
```
Support for typed arrays.
```js
var foo:uint8[] = [1, 2, 3, 4];
```
Support for nullable types.
```js
var foo:uint8? = null;
```
Function signatures with constraints.
```js
function Foo(a:int32, b:string, c:bignum[], callback:(string, bool)):int32 { }
```
Function overloading:
```js
function Foo(x:int32[]) { return "int32"; }
function Foo(s:string[]) { return "string"; }
Foo(["test"]); // "string"
```
So by default Number would convert implicitly with precedence given to decimal, float64, float32, uint64/32/16/8, int64/32/16/8. (Or whichever order makes the most sense).
Then lastly, support within the currently proposed class syntax to support multiple constructors and fixed size classes.
```js
// 4 byte object
value class myType
{
x:float32; // be able to define members outside of the constructor
constructor(x:float32)
{
this.x = x;
}
constructor(y:uint32)
{
this.x = float32(y) * 2;
}
}
```
```js
var t:myType = 1; // float32 implicit constructor call
```
Implicit constructors could also be added to the proposed SIMD classes to go from a scalar to a vector.
```js
var v:float32x4 = 1; // would be equivalent to var v = float32(1, 1, 1, 1);
```
These static typing rules expand the language greatly. They allow for other features to be added later like arrays of POD types:
```js
var t:myType[] = [1, 2, 3, uint32(1)];
```
That's not necessary though, but it's nice to keep that in mind.
Judging from previous conversations the idea of static typing for ECMAScript is over 10 years old, so any discussion would probably last for a few years. It would be nice to see a proposal written by someone familiar with the current issues along with the plans for the future to make an optional typing system seamless. Also I'm not proposing any form of a strict "using static"; or something since it's expected static and dynamic typing would be mixed a lot. Even in my examples with variadic functions it can be nice having untyped arguments. Having a single proposal for bringing up issues and more examples would be nice also.
Took a break while I worked on some Javascript projects for the past year to see if they'd give me more perspective on types. I'll keep this short though. Brendan Eich wrote: > No one is proposing type annotations a la ES4 or TypeScript, note well. I'm thinking the discussion needs to start up again for the sake of JS's future. Basically building a base for other languages and also making JS a more complete language by itself. Before I get into that though I have a few comments and questions. Starting with this video from Brendan Eich that was linked: https://www.youtube.com/watch?v=IXIkTrq3Rgg Regarding Literal Syntax ( http://www.slideshare.net/BrendanEich/js-resp/14 ) used in other languages I think Javascript could handle it cleaner without arbitrary suffixes like L, UL, f, n, and m. I'm not totally against the idea, but would constructors always work as an alternative? bignum(1234567890). If so it seems fine. (I just want to make sure the literal syntax is optional for all proposed types). The proposed operator overloading syntax ( http://www.slideshare.net/BrendanEich/js-resp/15 ) has the right idea, but I think partial classes might be a cleaner approach. Basically being able to define the same class multiple times and having their implementations merged ignoring duplicates. value class vector2d { x: float32; y: float32; get Length():float32 { return Math.sqrt(x * x + y * y); // uses Math.sqrt(v:float32):float32 due to input and return type } constructor(x:float32 = 0, y:float32 = 0) { this.x = x; this.y = y; } operator +(v:vector2d) { return vector2d(this.x + v.x, this.y + v.y); // return value type } operator ==(v:vector2d) { // equality check between this and v } } // In MyClass.js defined extensions to vector2d class vector2d { operator ==(v:MyClass) { // equality check between this and MyClass } } The implementation would then just need to update the current class definition as Javascript files are loaded. The other advantage with this is it allows for organization of operators which can be convenient for math objects that are required to work with many objects or third party code. For value type classes are they always passed by reference? I didn't see anything regarding pass by reference syntax. Do value classes have a copy constructor or something for cloning objects in that case? Okay onto typing. Ultimately what I'd like to happen is for an ECMA member to understand the value of static typing for JS and help turn this into a rough draft proposal that can be expanded on with critiques. What I keep seeing from years of conversation are comments like in this thread: https://esdiscuss.org/topic/optional-argument-types Brendan Eich wrote: > Types are hard. This doesn't mean "no, never". But big brains are still researching the general topic, and btw what Dart has can't be called types according to the researchers and literature I trust. There's not even a proposal for people to begin discussing the grammar and implications on JS though. It was given mild interest years ago, but it's past the time for putting off the discussion. (Also it doesn't look like anyone is against adding this. I've read a large part of the mailing list so far which discusses typing a lot). So what a static typing proposal should have at the minimal are the following types (lowercase seems to look best I think): bool string uint8/16/32/64 int8/16/32/64 float32/64 bignum decimal int32x4, int32x8 uint32x4, uint32x8 float32x4, float32x8 I saw the following mentioned in Brendan's slides and they'd probably be nice if a standardized interface and implementation is found: rational complex The ability to type any variable including lambdas. I'd go with the already proposed syntax that's been around for years. I've read the old guard and trademarks type proposals, but they seem unneeded for now. var foo:uint8 = 0; var foo = uint8(0); // cast var foo:(int32, string):string; // hold reference to a signature of this type var foo = (s:string, x:int32) => s + x; // implicit return type of string var foo = (x:uint8, y:uint8):uint16 => x + y; // explicit return type Support for typed arrays. var foo:uint8[] = [1, 2, 3, 4]; Support for nullable types. var foo:uint8? = null; Function signatures with constraints. function Foo(a:int32, b:string, c:bignum[], callback:(string, bool)):int32 { } Function overloading: function Foo(x:int32[]) { return "int32"; } function Foo(s:string[]) { return "string"; } Foo(["test"]); // "string" So by default Number would convert implicitly with precedence given to decimal, float64, float32, uint64/32/16/8, int64/32/16/8. (Or whichever order makes the most sense). Then lastly, support within the currently proposed class syntax to support multiple constructors and fixed size classes. // 4 byte object value class myType { x:float32; // be able to define members outside of the constructor constructor(x:float32) { this.x = x; } constructor(y:uint32) { this.x = float32(y) * 2; } } var t:myType = 1; // float32 implicit constructor call Implicit constructors could also be added to the proposed SIMD classes to go from a scalar to a vector. var v:float32x4 = 1; // would be equivalent to var v = float32(1, 1, 1, 1); These static typing rules expand the language greatly. They allow for other features to be added later like arrays of POD types: var t:myType[] = [1, 2, 3, uint32(1)]; That's not necessary though, but it's nice to keep that in mind. Judging from previous conversations the idea of static typing for ECMAScript is over 10 years old, so any discussion would probably last for a few years. It would be nice to see a proposal written by someone familiar with the current issues along with the plans for the future to make an optional typing system seamless. Also I'm not proposing any form of a strict "using static"; or something since it's expected static and dynamic typing would be mixed a lot. Even in my examples with variadic functions it can be nice having untyped arguments. Having a single proposal for bringing up issues and more examples would be nice also.