Proposal: Static Typing

Thu Apr 4 18:52:25 UTC 2019

>  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 <
andrea.giammarchi at gmail.com> 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 <kingmph at gmail.com> 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 <waldemar at google.com>
>> 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
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190404/dbd34bfe/attachment.html>