Proposal: Static Typing

Fri Apr 5 08:43:59 UTC 2019

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 <kingmph at gmail.com> 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 <
> 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/20190405/722398e9/attachment.html>