Proposal: Static Typing

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Static Typing

Michael Theriot


On Monday, March 25, 2019, ViliusCreator <[hidden email]> wrote:

```js

let a = 10

a += ‘1’ // ‘101’

// or

a += undefined // NaN

```

VS this:

```js

let a: number = 10

a += ‘1’ // Error, cannot convert type string to type number.

// or

a += undefined // Error, number doesn’t have nullable mark.

```

Thought experiment:

```js

let a = 10;
let b: number = 10;
a === b; // true

```

Would an error at runtime or compiletime occur here?

```js

a += '1'; // ok
b += '1'; // error

```

If it is a runtime error, is it optimal for the engine to keep track of typed variables vs regular for the same value?

If not and it is a compiletime error, what happens here?

```js

var x = something();

a += x;
b += x; // error?

```

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Static Typing

Claude Pache


Le 27 mars 2019 à 18:26, Michael Theriot <[hidden email]> a écrit :

Would an error at runtime or compiletime occur here?


The check cannot be reliably done at compile time in general; it must be a runtime check. (Tools may provide partial static analysis, but that’s an extra.)

The simplest reason is that statically typed code must run together with non-statically typed code.

And even ignoring legacy code, it is not desirable to have static types everywhere; for instance, `Array.prototype.sort()` must continue to work with both arrays of strings and arrays of numbers, and even with arrays of mixed types.

And even if everything everywhere was statically typed, you still cannot statically analyse situations like: `a = object[Math.random() < 0.5 ? "method_returning_number" : "method_returning_string"]()`.

If it is a runtime error, is it optimal for the engine to keep track of typed variables vs regular for the same value?

Today’s JS engines typically do already clever speculative optimisations based on expected types. For example: https://stackoverflow.com/a/46144917. So, I guess, it depends...

—Claude


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Fwd: Proposal: Static Typing

guest271314


---------- Forwarded message ---------
From: guest271314 <[hidden email]>
Date: Thu, Mar 28, 2019 at 12:19 AM
Subject: Re: Proposal: Static Typing
To: Claude Pache <[hidden email]>



> `a = object[Math.random() < 0.5 ? "method_returning_number" : "method_returning_string"]()`

Interesting case. See also

How do I check if a JavaScript function returns a Promise? 
Say I have two functions:
```function f1() {
    return new Promise<any>((resolve, reject) => {
        resolve(true);
    });
}
function f2() {
}```
How do I know if f1 will return Promise and f2 will not?

Can a regular expression be crafted which determines the return type of a function?

Has it been mathematically proven that antivirus can't detect all viruses?

On Wed, Mar 27, 2019 at 6:10 PM Claude Pache <[hidden email]> wrote:


Le 27 mars 2019 à 18:26, Michael Theriot <[hidden email]> a écrit :

Would an error at runtime or compiletime occur here?


The check cannot be reliably done at compile time in general; it must be a runtime check. (Tools may provide partial static analysis, but that’s an extra.)

The simplest reason is that statically typed code must run together with non-statically typed code.

And even ignoring legacy code, it is not desirable to have static types everywhere; for instance, `Array.prototype.sort()` must continue to work with both arrays of strings and arrays of numbers, and even with arrays of mixed types.

And even if everything everywhere was statically typed, you still cannot statically analyse situations like: `a = object[Math.random() < 0.5 ? "method_returning_number" : "method_returning_string"]()`.

If it is a runtime error, is it optimal for the engine to keep track of typed variables vs regular for the same value?

Today’s JS engines typically do already clever speculative optimisations based on expected types. For example: https://stackoverflow.com/a/46144917. So, I guess, it depends...

—Claude

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Static Typing

Ranando King
> Would an error at runtime or compiletime occur here?

There's no "compile time" per se in ES, but setting b += '1' when b is strictly typed shouldn't throw an error at all. The type of the '1' would be coerced to a number first, then added to b.

If instead it was something like
```js
let a: string = "1";
let b: number = 2;
b += a; //TypeError
```
This would cause an error because it would be invalid to coerce a into a number.

> If it is a runtime error, is it optimal for the engine to keep track of typed variables vs regular for the same value?

Engines like V8 already keep track of the type of variables. Static typing would simply add a flag to these types that prevents type coercion if set.

On Wed, Mar 27, 2019 at 7:20 PM guest271314 <[hidden email]> wrote:


---------- Forwarded message ---------
From: guest271314 <[hidden email]>
Date: Thu, Mar 28, 2019 at 12:19 AM
Subject: Re: Proposal: Static Typing
To: Claude Pache <[hidden email]>



> `a = object[Math.random() < 0.5 ? "method_returning_number" : "method_returning_string"]()`

Interesting case. See also

How do I check if a JavaScript function returns a Promise? 
Say I have two functions:
```function f1() {
    return new Promise<any>((resolve, reject) => {
        resolve(true);
    });
}
function f2() {
}```
How do I know if f1 will return Promise and f2 will not?

Can a regular expression be crafted which determines the return type of a function?

Has it been mathematically proven that antivirus can't detect all viruses?

On Wed, Mar 27, 2019 at 6:10 PM Claude Pache <[hidden email]> wrote:


Le 27 mars 2019 à 18:26, Michael Theriot <[hidden email]> a écrit :

Would an error at runtime or compiletime occur here?


The check cannot be reliably done at compile time in general; it must be a runtime check. (Tools may provide partial static analysis, but that’s an extra.)

The simplest reason is that statically typed code must run together with non-statically typed code.

And even ignoring legacy code, it is not desirable to have static types everywhere; for instance, `Array.prototype.sort()` must continue to work with both arrays of strings and arrays of numbers, and even with arrays of mixed types.

And even if everything everywhere was statically typed, you still cannot statically analyse situations like: `a = object[Math.random() < 0.5 ? "method_returning_number" : "method_returning_string"]()`.

If it is a runtime error, is it optimal for the engine to keep track of typed variables vs regular for the same value?

Today’s JS engines typically do already clever speculative optimisations based on expected types. For example: https://stackoverflow.com/a/46144917. So, I guess, it depends...

—Claude

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Static Typing

Waldemar Horwat
In reply to this post by ViliusCreator
On 3/23/19 1:34 PM, IdkGoodName Vilius wrote:
> This is a proposal for static typing. Here is the github repository link: https://github.com/CreatorVilius/Proposal-Static-Typing
> I think it would be great thing in JS.

We intentionally reserved syntax so that something like that would be possible in the future.

I've also spent a lot of time working on past proposals to do such things.  A few interesting issues would invariably arise that make both static and runtime typing unsound:

- If you allow user-defined types, objects can spontaneously change their type by mutating their prototype.  Thus, you can declare a variable x to have type Foo and check that you're assigning an instance of Foo to it, but the value x can become a Bar (different from a Foo) spontaneously without any operations on x.

- Something similar happens with trying to type arrays.  You wrote:

let c: auto = ['a', 'b']  // c is now string[]

but that begs the question of what is the type of just ['a', 'b'].

- Is it string[]?  No, it can't be that because you can replace its second element with a number.
- Is it any[]?  Well, in that case c should have type any[], not string[]
- Is it object?  In that case c should have type Object.
and so on.

If you follow this to its logical conclusion and think about what the types of various methods that work on arrays should be, you end up with an enormous and confusing variety of array and object types, which is something we explored years ago.  In some cases you'd want structural types, in some cases you'd want 'like' types (an array of anything which just happens to hold numbers at the moment), and so on.

     Waldemar
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Static Typing

Ranando King
> - If you allow user-defined types, objects can spontaneously change their type by mutating their prototype.  Thus, you can declare a variable x to have type Foo and check that you're assigning an instance of Foo to it, but the value x can become a Bar (different from a Foo) spontaneously without any operations on x.

At least for static typing, the engine will need to freeze a copy of the class definition at the time when the static type is referenced. That frozen type will be associated with the variable in a fixed way, making all attempts to change the type of the variable fail. Also, that would need to divorce the frozen type from the dynamic version so the dynamic version can still be mutated. That concept should work, but it might prove to be ridiculously complicated since it risks a proliferation of objects all of type Foo but with different type definitions. One way to get around that is to flag a type as static the first time it is used in a statically typed variable definition. This would cause an error to be thrown should any part of the class be altered. Not sure how workable that is.

> but that begs the question of what is the type of just ['a', 'b'].

It should be any[]. Typing should be as non-aggressive as possible. Auto typing should only consider the top level data to determine the type, and in this case, that's an Array. To make c restricted to string elements, the type would need to be specified as string[].

> If you follow this to its logical conclusion and think about what the types of various methods that work on arrays should be, you end up with an enormous and confusing variety of array and object types, which is something we explored years ago. 

Maybe, but that's always the case with any type system that allows for user-defined types. The main problem here is the memory requirements for storing all of those types. If I remember the description of V8 internals, it seems to have already managed this issue. At least in V8, the challenge would be in permanently associating a specific evolution of an internal type to a variable.

On Wed, Apr 3, 2019 at 7:50 PM Waldemar Horwat <[hidden email]> wrote:
On 3/23/19 1:34 PM, IdkGoodName Vilius wrote:
> This is a proposal for static typing. Here is the github repository link: https://github.com/CreatorVilius/Proposal-Static-Typing
> I think it would be great thing in JS.

We intentionally reserved syntax so that something like that would be possible in the future.

I've also spent a lot of time working on past proposals to do such things.  A few interesting issues would invariably arise that make both static and runtime typing unsound:

- If you allow user-defined types, objects can spontaneously change their type by mutating their prototype.  Thus, you can declare a variable x to have type Foo and check that you're assigning an instance of Foo to it, but the value x can become a Bar (different from a Foo) spontaneously without any operations on x.

- Something similar happens with trying to type arrays.  You wrote:

let c: auto = ['a', 'b']  // c is now string[]

but that begs the question of what is the type of just ['a', 'b'].

- Is it string[]?  No, it can't be that because you can replace its second element with a number.
- Is it any[]?  Well, in that case c should have type any[], not string[]
- Is it object?  In that case c should have type Object.
and so on.

If you follow this to its logical conclusion and think about what the types of various methods that work on arrays should be, you end up with an enormous and confusing variety of array and object types, which is something we explored years ago.  In some cases you'd want structural types, in some cases you'd want 'like' types (an array of anything which just happens to hold numbers at the moment), and so on.

     Waldemar
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Static Typing

Andrea Giammarchi-2
If something is missing, let's move forward finding out solutions, 'cause if we base any assumption only to the current highly dynamic nature of JS we won't go too far.

As example, I think the mutable prototype issue can be solved through static classes where no changes would be possible and all instances would be immune to `setPrototypeOf`

```
static class MyType {}

Reflect.setPrototypeOf(MyType, Array); // nope
Reflect.setPrototypeOf(new MyType, []); // nope
```

we'll also need a `Reflect.isTyped(ref)` in case we'd like to throw errors on prototype set attempts.



On Thu, Apr 4, 2019 at 6:11 AM Ranando King <[hidden email]> wrote:
> - If you allow user-defined types, objects can spontaneously change their type by mutating their prototype.  Thus, you can declare a variable x to have type Foo and check that you're assigning an instance of Foo to it, but the value x can become a Bar (different from a Foo) spontaneously without any operations on x.

At least for static typing, the engine will need to freeze a copy of the class definition at the time when the static type is referenced. That frozen type will be associated with the variable in a fixed way, making all attempts to change the type of the variable fail. Also, that would need to divorce the frozen type from the dynamic version so the dynamic version can still be mutated. That concept should work, but it might prove to be ridiculously complicated since it risks a proliferation of objects all of type Foo but with different type definitions. One way to get around that is to flag a type as static the first time it is used in a statically typed variable definition. This would cause an error to be thrown should any part of the class be altered. Not sure how workable that is.

> but that begs the question of what is the type of just ['a', 'b'].

It should be any[]. Typing should be as non-aggressive as possible. Auto typing should only consider the top level data to determine the type, and in this case, that's an Array. To make c restricted to string elements, the type would need to be specified as string[].

> If you follow this to its logical conclusion and think about what the types of various methods that work on arrays should be, you end up with an enormous and confusing variety of array and object types, which is something we explored years ago. 

Maybe, but that's always the case with any type system that allows for user-defined types. The main problem here is the memory requirements for storing all of those types. If I remember the description of V8 internals, it seems to have already managed this issue. At least in V8, the challenge would be in permanently associating a specific evolution of an internal type to a variable.

On Wed, Apr 3, 2019 at 7:50 PM Waldemar Horwat <[hidden email]> wrote:
On 3/23/19 1:34 PM, IdkGoodName Vilius wrote:
> This is a proposal for static typing. Here is the github repository link: https://github.com/CreatorVilius/Proposal-Static-Typing
> I think it would be great thing in JS.

We intentionally reserved syntax so that something like that would be possible in the future.

I've also spent a lot of time working on past proposals to do such things.  A few interesting issues would invariably arise that make both static and runtime typing unsound:

- If you allow user-defined types, objects can spontaneously change their type by mutating their prototype.  Thus, you can declare a variable x to have type Foo and check that you're assigning an instance of Foo to it, but the value x can become a Bar (different from a Foo) spontaneously without any operations on x.

- Something similar happens with trying to type arrays.  You wrote:

let c: auto = ['a', 'b']  // c is now string[]

but that begs the question of what is the type of just ['a', 'b'].

- Is it string[]?  No, it can't be that because you can replace its second element with a number.
- Is it any[]?  Well, in that case c should have type any[], not string[]
- Is it object?  In that case c should have type Object.
and so on.

If you follow this to its logical conclusion and think about what the types of various methods that work on arrays should be, you end up with an enormous and confusing variety of array and object types, which is something we explored years ago.  In some cases you'd want structural types, in some cases you'd want 'like' types (an array of anything which just happens to hold numbers at the moment), and so on.

     Waldemar
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Static Typing

Ranando King
>  if we base any assumption only to the current highly dynamic nature of JS we won't go too far.

Problem is that if we infringe on the "current highly dynamic nature of JS", we'll end up breaking valuable use cases. Any new feature added should always be 100% compatible with the non-competing portions of the existing language.

> I think the mutable prototype issue can be solved through static classes where no changes would be possible and all instances would be immune to `setPrototypeOf`

That solves half of the problem. What of the other half (`Type v = "somevalue";` where `Type` is not a static class)? With your approach, that would need to be restricted to solve the other half. Otherwise, you'd still be facing the issues Waldemar spoke about.

On Thu, Apr 4, 2019 at 2:49 AM Andrea Giammarchi <[hidden email]> wrote:
If something is missing, let's move forward finding out solutions, 'cause if we base any assumption only to the current highly dynamic nature of JS we won't go too far.

As example, I think the mutable prototype issue can be solved through static classes where no changes would be possible and all instances would be immune to `setPrototypeOf`

```
static class MyType {}

Reflect.setPrototypeOf(MyType, Array); // nope
Reflect.setPrototypeOf(new MyType, []); // nope
```

we'll also need a `Reflect.isTyped(ref)` in case we'd like to throw errors on prototype set attempts.



On Thu, Apr 4, 2019 at 6:11 AM Ranando King <[hidden email]> wrote:
> - If you allow user-defined types, objects can spontaneously change their type by mutating their prototype.  Thus, you can declare a variable x to have type Foo and check that you're assigning an instance of Foo to it, but the value x can become a Bar (different from a Foo) spontaneously without any operations on x.

At least for static typing, the engine will need to freeze a copy of the class definition at the time when the static type is referenced. That frozen type will be associated with the variable in a fixed way, making all attempts to change the type of the variable fail. Also, that would need to divorce the frozen type from the dynamic version so the dynamic version can still be mutated. That concept should work, but it might prove to be ridiculously complicated since it risks a proliferation of objects all of type Foo but with different type definitions. One way to get around that is to flag a type as static the first time it is used in a statically typed variable definition. This would cause an error to be thrown should any part of the class be altered. Not sure how workable that is.

> but that begs the question of what is the type of just ['a', 'b'].

It should be any[]. Typing should be as non-aggressive as possible. Auto typing should only consider the top level data to determine the type, and in this case, that's an Array. To make c restricted to string elements, the type would need to be specified as string[].

> If you follow this to its logical conclusion and think about what the types of various methods that work on arrays should be, you end up with an enormous and confusing variety of array and object types, which is something we explored years ago. 

Maybe, but that's always the case with any type system that allows for user-defined types. The main problem here is the memory requirements for storing all of those types. If I remember the description of V8 internals, it seems to have already managed this issue. At least in V8, the challenge would be in permanently associating a specific evolution of an internal type to a variable.

On Wed, Apr 3, 2019 at 7:50 PM Waldemar Horwat <[hidden email]> wrote:
On 3/23/19 1:34 PM, IdkGoodName Vilius wrote:
> This is a proposal for static typing. Here is the github repository link: https://github.com/CreatorVilius/Proposal-Static-Typing
> I think it would be great thing in JS.

We intentionally reserved syntax so that something like that would be possible in the future.

I've also spent a lot of time working on past proposals to do such things.  A few interesting issues would invariably arise that make both static and runtime typing unsound:

- If you allow user-defined types, objects can spontaneously change their type by mutating their prototype.  Thus, you can declare a variable x to have type Foo and check that you're assigning an instance of Foo to it, but the value x can become a Bar (different from a Foo) spontaneously without any operations on x.

- Something similar happens with trying to type arrays.  You wrote:

let c: auto = ['a', 'b']  // c is now string[]

but that begs the question of what is the type of just ['a', 'b'].

- Is it string[]?  No, it can't be that because you can replace its second element with a number.
- Is it any[]?  Well, in that case c should have type any[], not string[]
- Is it object?  In that case c should have type Object.
and so on.

If you follow this to its logical conclusion and think about what the types of various methods that work on arrays should be, you end up with an enormous and confusing variety of array and object types, which is something we explored years ago.  In some cases you'd want structural types, in some cases you'd want 'like' types (an array of anything which just happens to hold numbers at the moment), and so on.

     Waldemar
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Static Typing

Andrea Giammarchi-2
we could add a `Typed` primitive every typed value inherits from, similar way every object implicitly inherits from `Object` these days.

That, by contract, would disallow any prototype related operation to either classes or instances, and it will simplify the `Reflect.isTyped(thing)` algo.

class MyType extends Typed {}
const num:i32 = 123;

the `MyType` class, and every instance of it, cannot have mutated prototype, and so cannot the `num`.

Typed values will be all shortcuts that behave like a Typed instance.

That should solves all cases, right?





On Thu, Apr 4, 2019 at 8:52 PM Ranando King <[hidden email]> wrote:
>  if we base any assumption only to the current highly dynamic nature of JS we won't go too far.

Problem is that if we infringe on the "current highly dynamic nature of JS", we'll end up breaking valuable use cases. Any new feature added should always be 100% compatible with the non-competing portions of the existing language.

> I think the mutable prototype issue can be solved through static classes where no changes would be possible and all instances would be immune to `setPrototypeOf`

That solves half of the problem. What of the other half (`Type v = "somevalue";` where `Type` is not a static class)? With your approach, that would need to be restricted to solve the other half. Otherwise, you'd still be facing the issues Waldemar spoke about.

On Thu, Apr 4, 2019 at 2:49 AM Andrea Giammarchi <[hidden email]> wrote:
If something is missing, let's move forward finding out solutions, 'cause if we base any assumption only to the current highly dynamic nature of JS we won't go too far.

As example, I think the mutable prototype issue can be solved through static classes where no changes would be possible and all instances would be immune to `setPrototypeOf`

```
static class MyType {}

Reflect.setPrototypeOf(MyType, Array); // nope
Reflect.setPrototypeOf(new MyType, []); // nope
```

we'll also need a `Reflect.isTyped(ref)` in case we'd like to throw errors on prototype set attempts.



On Thu, Apr 4, 2019 at 6:11 AM Ranando King <[hidden email]> wrote:
> - If you allow user-defined types, objects can spontaneously change their type by mutating their prototype.  Thus, you can declare a variable x to have type Foo and check that you're assigning an instance of Foo to it, but the value x can become a Bar (different from a Foo) spontaneously without any operations on x.

At least for static typing, the engine will need to freeze a copy of the class definition at the time when the static type is referenced. That frozen type will be associated with the variable in a fixed way, making all attempts to change the type of the variable fail. Also, that would need to divorce the frozen type from the dynamic version so the dynamic version can still be mutated. That concept should work, but it might prove to be ridiculously complicated since it risks a proliferation of objects all of type Foo but with different type definitions. One way to get around that is to flag a type as static the first time it is used in a statically typed variable definition. This would cause an error to be thrown should any part of the class be altered. Not sure how workable that is.

> but that begs the question of what is the type of just ['a', 'b'].

It should be any[]. Typing should be as non-aggressive as possible. Auto typing should only consider the top level data to determine the type, and in this case, that's an Array. To make c restricted to string elements, the type would need to be specified as string[].

> If you follow this to its logical conclusion and think about what the types of various methods that work on arrays should be, you end up with an enormous and confusing variety of array and object types, which is something we explored years ago. 

Maybe, but that's always the case with any type system that allows for user-defined types. The main problem here is the memory requirements for storing all of those types. If I remember the description of V8 internals, it seems to have already managed this issue. At least in V8, the challenge would be in permanently associating a specific evolution of an internal type to a variable.

On Wed, Apr 3, 2019 at 7:50 PM Waldemar Horwat <[hidden email]> wrote:
On 3/23/19 1:34 PM, IdkGoodName Vilius wrote:
> This is a proposal for static typing. Here is the github repository link: https://github.com/CreatorVilius/Proposal-Static-Typing
> I think it would be great thing in JS.

We intentionally reserved syntax so that something like that would be possible in the future.

I've also spent a lot of time working on past proposals to do such things.  A few interesting issues would invariably arise that make both static and runtime typing unsound:

- If you allow user-defined types, objects can spontaneously change their type by mutating their prototype.  Thus, you can declare a variable x to have type Foo and check that you're assigning an instance of Foo to it, but the value x can become a Bar (different from a Foo) spontaneously without any operations on x.

- Something similar happens with trying to type arrays.  You wrote:

let c: auto = ['a', 'b']  // c is now string[]

but that begs the question of what is the type of just ['a', 'b'].

- Is it string[]?  No, it can't be that because you can replace its second element with a number.
- Is it any[]?  Well, in that case c should have type any[], not string[]
- Is it object?  In that case c should have type Object.
and so on.

If you follow this to its logical conclusion and think about what the types of various methods that work on arrays should be, you end up with an enormous and confusing variety of array and object types, which is something we explored years ago.  In some cases you'd want structural types, in some cases you'd want 'like' types (an array of anything which just happens to hold numbers at the moment), and so on.

     Waldemar
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Static Typing

Ranando King
>  That should solves all cases, right?

Only if a non `:any` type **must** extend `Typed()`. Put another way:

class MyType extends Typed {}
class OtherType {}

let a: any = new Object; //Valid
let b: OtherType; //Error: Invalid type specification
let c: MyType = new Object; //Error: Invalid cast assignment
let d: MyType = new MyType; //Valid


On Fri, Apr 5, 2019 at 3:44 AM Andrea Giammarchi <[hidden email]> wrote:
we could add a `Typed` primitive every typed value inherits from, similar way every object implicitly inherits from `Object` these days.

That, by contract, would disallow any prototype related operation to either classes or instances, and it will simplify the `Reflect.isTyped(thing)` algo.

class MyType extends Typed {}
const num:i32 = 123;

the `MyType` class, and every instance of it, cannot have mutated prototype, and so cannot the `num`.

Typed values will be all shortcuts that behave like a Typed instance.

That should solves all cases, right?





On Thu, Apr 4, 2019 at 8:52 PM Ranando King <[hidden email]> wrote:
>  if we base any assumption only to the current highly dynamic nature of JS we won't go too far.

Problem is that if we infringe on the "current highly dynamic nature of JS", we'll end up breaking valuable use cases. Any new feature added should always be 100% compatible with the non-competing portions of the existing language.

> I think the mutable prototype issue can be solved through static classes where no changes would be possible and all instances would be immune to `setPrototypeOf`

That solves half of the problem. What of the other half (`Type v = "somevalue";` where `Type` is not a static class)? With your approach, that would need to be restricted to solve the other half. Otherwise, you'd still be facing the issues Waldemar spoke about.

On Thu, Apr 4, 2019 at 2:49 AM Andrea Giammarchi <[hidden email]> wrote:
If something is missing, let's move forward finding out solutions, 'cause if we base any assumption only to the current highly dynamic nature of JS we won't go too far.

As example, I think the mutable prototype issue can be solved through static classes where no changes would be possible and all instances would be immune to `setPrototypeOf`

```
static class MyType {}

Reflect.setPrototypeOf(MyType, Array); // nope
Reflect.setPrototypeOf(new MyType, []); // nope
```

we'll also need a `Reflect.isTyped(ref)` in case we'd like to throw errors on prototype set attempts.



On Thu, Apr 4, 2019 at 6:11 AM Ranando King <[hidden email]> wrote:
> - If you allow user-defined types, objects can spontaneously change their type by mutating their prototype.  Thus, you can declare a variable x to have type Foo and check that you're assigning an instance of Foo to it, but the value x can become a Bar (different from a Foo) spontaneously without any operations on x.

At least for static typing, the engine will need to freeze a copy of the class definition at the time when the static type is referenced. That frozen type will be associated with the variable in a fixed way, making all attempts to change the type of the variable fail. Also, that would need to divorce the frozen type from the dynamic version so the dynamic version can still be mutated. That concept should work, but it might prove to be ridiculously complicated since it risks a proliferation of objects all of type Foo but with different type definitions. One way to get around that is to flag a type as static the first time it is used in a statically typed variable definition. This would cause an error to be thrown should any part of the class be altered. Not sure how workable that is.

> but that begs the question of what is the type of just ['a', 'b'].

It should be any[]. Typing should be as non-aggressive as possible. Auto typing should only consider the top level data to determine the type, and in this case, that's an Array. To make c restricted to string elements, the type would need to be specified as string[].

> If you follow this to its logical conclusion and think about what the types of various methods that work on arrays should be, you end up with an enormous and confusing variety of array and object types, which is something we explored years ago. 

Maybe, but that's always the case with any type system that allows for user-defined types. The main problem here is the memory requirements for storing all of those types. If I remember the description of V8 internals, it seems to have already managed this issue. At least in V8, the challenge would be in permanently associating a specific evolution of an internal type to a variable.

On Wed, Apr 3, 2019 at 7:50 PM Waldemar Horwat <[hidden email]> wrote:
On 3/23/19 1:34 PM, IdkGoodName Vilius wrote:
> This is a proposal for static typing. Here is the github repository link: https://github.com/CreatorVilius/Proposal-Static-Typing
> I think it would be great thing in JS.

We intentionally reserved syntax so that something like that would be possible in the future.

I've also spent a lot of time working on past proposals to do such things.  A few interesting issues would invariably arise that make both static and runtime typing unsound:

- If you allow user-defined types, objects can spontaneously change their type by mutating their prototype.  Thus, you can declare a variable x to have type Foo and check that you're assigning an instance of Foo to it, but the value x can become a Bar (different from a Foo) spontaneously without any operations on x.

- Something similar happens with trying to type arrays.  You wrote:

let c: auto = ['a', 'b']  // c is now string[]

but that begs the question of what is the type of just ['a', 'b'].

- Is it string[]?  No, it can't be that because you can replace its second element with a number.
- Is it any[]?  Well, in that case c should have type any[], not string[]
- Is it object?  In that case c should have type Object.
and so on.

If you follow this to its logical conclusion and think about what the types of various methods that work on arrays should be, you end up with an enormous and confusing variety of array and object types, which is something we explored years ago.  In some cases you'd want structural types, in some cases you'd want 'like' types (an array of anything which just happens to hold numbers at the moment), and so on.

     Waldemar
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Static Typing

guest271314
In reply to this post by ViliusCreator
Two possible solutions to the requirement of not being able to change a "type" both include utilizing `const`.

1. Using `Object.freeze()`

`const x = Object.freez([1,2,3])`

2. Using `Promise.resolve()`

`const x = Promise.resolve([1,2,3])`

neither of which can be deleted or changed within the current scope.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Static Typing

guest271314
In reply to this post by ViliusCreator

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Static Typing

Jordan Harband
In reply to this post by guest271314
`const` means it can't be reassigned, but a non-frozen value can still have its properties changed or its [[Prototype]] changed (including Promise, which could have its `.then` method changed), which would change the type.

On Fri, Apr 5, 2019 at 11:36 AM guest271314 <[hidden email]> wrote:
Two possible solutions to the requirement of not being able to change a "type" both include utilizing `const`.

1. Using `Object.freeze()`

`const x = Object.freez([1,2,3])`

2. Using `Promise.resolve()`

`const x = Promise.resolve([1,2,3])`

neither of which can be deleted or changed within the current scope.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Static Typing

Ranando King
In reply to this post by guest271314
Similar but not the same. Within any given scope, a Type declared within that scope would need to be "set-in-stone" to be of any value. Furthermore, for a variable to honor that type, it must be able to carry around an unmodified reference to the tyoe as it existed at the time the variable was declared. If either one of these two conditions is not met, then the type system cannot claim to be static. It would be more of an "advisory" dynamic type system, where the specified type gives the engine a hint on what kind of data will be stored in a given variable.

On Fri, Apr 5, 2019 at 1:51 PM guest271314 <[hidden email]> wrote:
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12