Proposal: Static Typing

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

Proposal: Static Typing

ViliusCreator
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.

_______________________________________________
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
Just my personal thoughts on this.

The way PHP migrated to types has been thought incremental steps, and it worked pretty well.

Since types have been demanded by the JS community for a while, I think it'd be key to approach JS types not all at once, but through smaller iterations.

As example, a proposal with a whole section entitled "Other useless things" would easily diverge focus to stuff the is really not necessary at this point.

Since types are also pretty much only a tooling convention, starting just with the most basic need/help, and iterate more complex cases later on, would be probably the best way to go.

Reading though all suggestions, I personally think these would be a no brainer to specify and ship as first iteration:
  • primitives mean primitives (i.e. `string` means `typeof "string"`, no strings attached)
  • Classes and Built-ins mean classes and built-ins (i.e` String` means any `instanceof String`)
  • enum could be a new primitive (as in `typeof "enum"`, since static and immutable) but also an expression (like classes), for enums defined as properties/fields of literals and classes
  • I actually like the `auto` name more than `any`, but without signature overloads/rides the use case would be too broad, so that maybe we should have a way to also define multiple types (i.e. `const notFullyAuto: String|Object|string = value;`)
  • while I know it's pretty common to have `number[]` as type to define an array of numbers, I also don't understand why a new syntax should have already two different ways to define typed array, i.e. `const list:number[]` and `const list:[number]`, so since the latter one is more powerful/flexible, to define also multiple key/value pairs, maybe that's all we need
With these basics, the JS world would already have a huge change.

Things we might consider, but me might also don't care about, since these behaviors are part of the specs:
  • `object` would accept `null`, but since there is no `typeof "null"`, the way to ensure `null` won't be there is to use `Object` instead. Are we OK with that?
  • `number` would accept `NaN` and `-/Infinity`, but IMO that's the case also without types, if a number is expected. Are we OK with that?
  • to avoid confusion with binary `|` operations, maybe multiple types could be wrapped in brackets, so that `const index:{number|string}` might look better?
That's it for my idea on how this could start moving forward.

Best Regards





On Sat, Mar 23, 2019 at 9:37 PM IdkGoodName Vilius <[hidden email]> 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.
_______________________________________________
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

Sultan
Counter proposal: A uniform signature for types, denoted by:

const name: primitive-type<arguments...>?;

Where primitive types are denoted as:

const name: symbol;
const name: string;
const name: number;
const name: object;
const name: boolean;
const name: function;

And types can later be extended to afford additional meta data as needed:

const name: string<10>; // string of length 10
const name: number<float>; // floating point number, as opposed to BigInt

const name: object<[]>; // array object
const name: object<Node>; // Node object

Union types can get added later, and denoted as: 

const name: union<string, number>;

Functions can later be afforded return and argument types as denoted by:

function<void> fn (a: object<[], number>, b: string<10>?) {
return
}

const fn: function<void> = (a: object<[], number>, b: string<10>?) => {
return
}

On Sun, Mar 24, 2019 at 3:19 PM Andrea Giammarchi <[hidden email]> wrote:
Just my personal thoughts on this.

The way PHP migrated to types has been thought incremental steps, and it worked pretty well.

Since types have been demanded by the JS community for a while, I think it'd be key to approach JS types not all at once, but through smaller iterations.

As example, a proposal with a whole section entitled "Other useless things" would easily diverge focus to stuff the is really not necessary at this point.

Since types are also pretty much only a tooling convention, starting just with the most basic need/help, and iterate more complex cases later on, would be probably the best way to go.

Reading though all suggestions, I personally think these would be a no brainer to specify and ship as first iteration:
  • primitives mean primitives (i.e. `string` means `typeof "string"`, no strings attached)
  • Classes and Built-ins mean classes and built-ins (i.e` String` means any `instanceof String`)
  • enum could be a new primitive (as in `typeof "enum"`, since static and immutable) but also an expression (like classes), for enums defined as properties/fields of literals and classes
  • I actually like the `auto` name more than `any`, but without signature overloads/rides the use case would be too broad, so that maybe we should have a way to also define multiple types (i.e. `const notFullyAuto: String|Object|string = value;`)
  • while I know it's pretty common to have `number[]` as type to define an array of numbers, I also don't understand why a new syntax should have already two different ways to define typed array, i.e. `const list:number[]` and `const list:[number]`, so since the latter one is more powerful/flexible, to define also multiple key/value pairs, maybe that's all we need
With these basics, the JS world would already have a huge change.

Things we might consider, but me might also don't care about, since these behaviors are part of the specs:
  • `object` would accept `null`, but since there is no `typeof "null"`, the way to ensure `null` won't be there is to use `Object` instead. Are we OK with that?
  • `number` would accept `NaN` and `-/Infinity`, but IMO that's the case also without types, if a number is expected. Are we OK with that?
  • to avoid confusion with binary `|` operations, maybe multiple types could be wrapped in brackets, so that `const index:{number|string}` might look better?
That's it for my idea on how this could start moving forward.

Best Regards





On Sat, Mar 23, 2019 at 9:37 PM IdkGoodName Vilius <[hidden email]> 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.
_______________________________________________
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

Bergi
In reply to this post by ViliusCreator
Hello,
to play the devils advocate: why does JavaScript need static typing?

Your proposal doesn't really answer that. Sure, it mentions tooling and
IDEs that can provide you with type hints and complain on mistakes, but
things like Flow and Typescript do this today already.
What's your goal, to have JS engines run Typescript(-like) code natively
without transpiling? For backwards-compatibility you'd have to do that
anyway, especially if new type system features are introduced incrementally.

What's the point of building this feature into engines? It just provides
additional complexity. Not to mention the difficulty of finding a
suitable type system that is both sophisticated enough to describe all
useful code (not taking away too much flexibility) and simple enough to
understand without a CS degree. And which interfaces well with un-typed
completely dynamic code.

What does "static typing" even mean to you in a dynamic scripting
language? JavaScript is not compiled by the developer, it is run by the
user. Where (when) do you expect types to be checked? Should the engine
throw early errors (during parsing)? During parsing of which parts of
the code, even when "normal" (untyped) code is calling into typed code?
Or do you expect dynamic runtime errors, like when assigning an invalid
value to a "typed variable" or calling a "typed function" with wrong
arguments? Are type definitions completely constant or could they be
mutated/extended/etc dynamically (and what happens when you introduce
new types with `eval` or by loading another script)?

A proposal would need to provide an objective that answers all these
questions, before even considering any particular type system or syntax.

One way to go forward that I can see would be a proposal that reserves a
relatively unrestricted syntax for type annotations (which are already
considered during every grammar amendment anyway, for compatibility with
Flow/Typescript), but not assign any semantics to them and require
engines to simply ignore them. External tooling could then use these
annotations according to its own rules.

kind regards,
  Bergi
_______________________________________________
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

kai zhu
i share a similar concern that static-typing makes little sense in high-churn-rate UX-workflow-programming.

it encourage people to bikeshed for correctness, on low-level code that frequently gets rewritten every few weeks/months -- and with often demoralizing effects.

> On 24 Mar 2019, at 17:26, Bergi <[hidden email]> wrote:
>
> Hello,
> to play the devils advocate: why does JavaScript need static typing?
>
> Your proposal doesn't really answer that. Sure, it mentions tooling and
> IDEs that can provide you with type hints and complain on mistakes, but
> things like Flow and Typescript do this today already.
> What's your goal, to have JS engines run Typescript(-like) code natively
> without transpiling? For backwards-compatibility you'd have to do that
> anyway, especially if new type system features are introduced incrementally.
>
> What's the point of building this feature into engines? It just provides
> additional complexity. Not to mention the difficulty of finding a
> suitable type system that is both sophisticated enough to describe all
> useful code (not taking away too much flexibility) and simple enough to
> understand without a CS degree. And which interfaces well with un-typed
> completely dynamic code.
>
> What does "static typing" even mean to you in a dynamic scripting
> language? JavaScript is not compiled by the developer, it is run by the
> user. Where (when) do you expect types to be checked? Should the engine
> throw early errors (during parsing)? During parsing of which parts of
> the code, even when "normal" (untyped) code is calling into typed code?
> Or do you expect dynamic runtime errors, like when assigning an invalid
> value to a "typed variable" or calling a "typed function" with wrong
> arguments? Are type definitions completely constant or could they be
> mutated/extended/etc dynamically (and what happens when you introduce
> new types with `eval` or by loading another script)?
>
> A proposal would need to provide an objective that answers all these
> questions, before even considering any particular type system or syntax.
>
> One way to go forward that I can see would be a proposal that reserves a
> relatively unrestricted syntax for type annotations (which are already
> considered during every grammar amendment anyway, for compatibility with
> Flow/Typescript), but not assign any semantics to them and require
> engines to simply ignore them. External tooling could then use these
> annotations according to its own rules.
>
> kind regards,
> Bergi
> _______________________________________________
> 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
One thing is definitively true. Any static type system added to ES must not be mandatory. Untyped code must be able to call typed code without forcing references into a fixed type. Likewise, typed code must be able to call untyped code without forcing references to give up type guarantees.

On Sun, Mar 24, 2019 at 8:48 PM kai zhu <[hidden email]> wrote:
i share a similar concern that static-typing makes little sense in high-churn-rate UX-workflow-programming.

it encourage people to bikeshed for correctness, on low-level code that frequently gets rewritten every few weeks/months -- and with often demoralizing effects.

> On 24 Mar 2019, at 17:26, Bergi <[hidden email]> wrote:
>
> Hello,
> to play the devils advocate: why does JavaScript need static typing?
>
> Your proposal doesn't really answer that. Sure, it mentions tooling and
> IDEs that can provide you with type hints and complain on mistakes, but
> things like Flow and Typescript do this today already.
> What's your goal, to have JS engines run Typescript(-like) code natively
> without transpiling? For backwards-compatibility you'd have to do that
> anyway, especially if new type system features are introduced incrementally.
>
> What's the point of building this feature into engines? It just provides
> additional complexity. Not to mention the difficulty of finding a
> suitable type system that is both sophisticated enough to describe all
> useful code (not taking away too much flexibility) and simple enough to
> understand without a CS degree. And which interfaces well with un-typed
> completely dynamic code.
>
> What does "static typing" even mean to you in a dynamic scripting
> language? JavaScript is not compiled by the developer, it is run by the
> user. Where (when) do you expect types to be checked? Should the engine
> throw early errors (during parsing)? During parsing of which parts of
> the code, even when "normal" (untyped) code is calling into typed code?
> Or do you expect dynamic runtime errors, like when assigning an invalid
> value to a "typed variable" or calling a "typed function" with wrong
> arguments? Are type definitions completely constant or could they be
> mutated/extended/etc dynamically (and what happens when you introduce
> new types with `eval` or by loading another script)?
>
> A proposal would need to provide an objective that answers all these
> questions, before even considering any particular type system or syntax.
>
> One way to go forward that I can see would be a proposal that reserves a
> relatively unrestricted syntax for type annotations (which are already
> considered during every grammar amendment anyway, for compatibility with
> Flow/Typescript), but not assign any semantics to them and require
> engines to simply ignore them. External tooling could then use these
> annotations according to its own rules.
>
> kind regards,
> Bergi
> _______________________________________________
> 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

Naveen Chawla
Yes the real value of strict types, in my view, is at development time, not at run time.

However I would be curious to know if anybody has a usage for them at run time, and an example of such a case...

Otherwise, yes a "toolchain" that allows strict typing using JavaScript without having to "use TypeScript".

On Mon, 25 Mar 2019 at 04:58, Ranando King <[hidden email]> wrote:
One thing is definitively true. Any static type system added to ES must not be mandatory. Untyped code must be able to call typed code without forcing references into a fixed type. Likewise, typed code must be able to call untyped code without forcing references to give up type guarantees.

On Sun, Mar 24, 2019 at 8:48 PM kai zhu <[hidden email]> wrote:
i share a similar concern that static-typing makes little sense in high-churn-rate UX-workflow-programming.

it encourage people to bikeshed for correctness, on low-level code that frequently gets rewritten every few weeks/months -- and with often demoralizing effects.

> On 24 Mar 2019, at 17:26, Bergi <[hidden email]> wrote:
>
> Hello,
> to play the devils advocate: why does JavaScript need static typing?
>
> Your proposal doesn't really answer that. Sure, it mentions tooling and
> IDEs that can provide you with type hints and complain on mistakes, but
> things like Flow and Typescript do this today already.
> What's your goal, to have JS engines run Typescript(-like) code natively
> without transpiling? For backwards-compatibility you'd have to do that
> anyway, especially if new type system features are introduced incrementally.
>
> What's the point of building this feature into engines? It just provides
> additional complexity. Not to mention the difficulty of finding a
> suitable type system that is both sophisticated enough to describe all
> useful code (not taking away too much flexibility) and simple enough to
> understand without a CS degree. And which interfaces well with un-typed
> completely dynamic code.
>
> What does "static typing" even mean to you in a dynamic scripting
> language? JavaScript is not compiled by the developer, it is run by the
> user. Where (when) do you expect types to be checked? Should the engine
> throw early errors (during parsing)? During parsing of which parts of
> the code, even when "normal" (untyped) code is calling into typed code?
> Or do you expect dynamic runtime errors, like when assigning an invalid
> value to a "typed variable" or calling a "typed function" with wrong
> arguments? Are type definitions completely constant or could they be
> mutated/extended/etc dynamically (and what happens when you introduce
> new types with `eval` or by loading another script)?
>
> A proposal would need to provide an objective that answers all these
> questions, before even considering any particular type system or syntax.
>
> One way to go forward that I can see would be a proposal that reserves a
> relatively unrestricted syntax for type annotations (which are already
> considered during every grammar amendment anyway, for compatibility with
> Flow/Typescript), but not assign any semantics to them and require
> engines to simply ignore them. External tooling could then use these
> annotations according to its own rules.
>
> kind regards,
> Bergi
> _______________________________________________
> 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

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

Re: Re: Proposal: Static Typing

Засим Александр
In reply to this post by ViliusCreator

What about performance? Would strict types improve JIT compilation?

 

 


_______________________________________________
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
In reply to this post by Naveen Chawla
I am having hard time understanding the counter argument "you need a transpolar anyway".

That's been the case since ES2015 landed with breaking syntax that has been required mandatory transpilation to keep it backward compatible, with things also not really transpilble such as classes with built-in extends ability.

Why suddenly the "need to transpile" is considered a point against any new JS feature? Are we already done with JS, if that's the case?

TypeScript exists and it has its own problems, 'cause its slightly diversions from what's defined via TC39 causes just confusion (i.e. private fields, to name one, built-in extends still broken if you target ES5, while Babel 7 fixed that, and template literals behave differently too - Babel 7 is the only one producing a standard behavior)

On top of that, many things recently landed in JS has been inspired by CoffeeScript ... where was the "just use CoffeeScript" argument at that time? Transpilers were already a thing then too.

Moreover ...

> the real value of strict types, in my view, is at development time, not at run time.

This is not correct. Check what AssemblyScript managed to do via types, targeting WASM instead of non-typed JS

If TypeScript, with its quirks, will be the language that help developers and win JS in the WASM field, we can start considering JS a second class citizen of the Web (and soon of the backend too, see deno).

Is this where we are with JS?

> I would be curious to know if anybody has a usage for them at run time

Developers might not have such usage, but V8 / Chackra / JSC / SpiderMonkey might spin up optimizations ahead of time, enabling right away hot code.

> a "toolchain" that allows strict typing using JavaScript without having to "use TypeScript".

even if it'll end up being identical or redundant, but I doubt it, for many companies/teams the least third parts dependencies you have the better is for code reliability.

I personally don't trust TS because it breaks when it targets ES5 and I cannot control what other people target, but I would trust the standard path and tools aiming at all cost to trample it right, whenever transpiring is needed.

With Edge moving to use Chrome, and Firefox and WebKit always catching up, these days introducing anything new might need transpilers just for a couple of years, instead of decades.

Best Regards





On Mon, Mar 25, 2019 at 9:55 AM Naveen Chawla <[hidden email]> wrote:
Yes the real value of strict types, in my view, is at development time, not at run time.

However I would be curious to know if anybody has a usage for them at run time, and an example of such a case...

Otherwise, yes a "toolchain" that allows strict typing using JavaScript without having to "use TypeScript".

On Mon, 25 Mar 2019 at 04:58, Ranando King <[hidden email]> wrote:
One thing is definitively true. Any static type system added to ES must not be mandatory. Untyped code must be able to call typed code without forcing references into a fixed type. Likewise, typed code must be able to call untyped code without forcing references to give up type guarantees.

On Sun, Mar 24, 2019 at 8:48 PM kai zhu <[hidden email]> wrote:
i share a similar concern that static-typing makes little sense in high-churn-rate UX-workflow-programming.

it encourage people to bikeshed for correctness, on low-level code that frequently gets rewritten every few weeks/months -- and with often demoralizing effects.

> On 24 Mar 2019, at 17:26, Bergi <[hidden email]> wrote:
>
> Hello,
> to play the devils advocate: why does JavaScript need static typing?
>
> Your proposal doesn't really answer that. Sure, it mentions tooling and
> IDEs that can provide you with type hints and complain on mistakes, but
> things like Flow and Typescript do this today already.
> What's your goal, to have JS engines run Typescript(-like) code natively
> without transpiling? For backwards-compatibility you'd have to do that
> anyway, especially if new type system features are introduced incrementally.
>
> What's the point of building this feature into engines? It just provides
> additional complexity. Not to mention the difficulty of finding a
> suitable type system that is both sophisticated enough to describe all
> useful code (not taking away too much flexibility) and simple enough to
> understand without a CS degree. And which interfaces well with un-typed
> completely dynamic code.
>
> What does "static typing" even mean to you in a dynamic scripting
> language? JavaScript is not compiled by the developer, it is run by the
> user. Where (when) do you expect types to be checked? Should the engine
> throw early errors (during parsing)? During parsing of which parts of
> the code, even when "normal" (untyped) code is calling into typed code?
> Or do you expect dynamic runtime errors, like when assigning an invalid
> value to a "typed variable" or calling a "typed function" with wrong
> arguments? Are type definitions completely constant or could they be
> mutated/extended/etc dynamically (and what happens when you introduce
> new types with `eval` or by loading another script)?
>
> A proposal would need to provide an objective that answers all these
> questions, before even considering any particular type system or syntax.
>
> One way to go forward that I can see would be a proposal that reserves a
> relatively unrestricted syntax for type annotations (which are already
> considered during every grammar amendment anyway, for compatibility with
> Flow/Typescript), but not assign any semantics to them and require
> engines to simply ignore them. External tooling could then use these
> annotations according to its own rules.
>
> kind regards,
> Bergi
> _______________________________________________
> 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
_______________________________________________
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
the day I'll disable autocorrect everywhere will be always too late ...

transpolar => transpilers
trample => transpile





On Mon, Mar 25, 2019 at 10:13 AM Andrea Giammarchi <[hidden email]> wrote:
I am having hard time understanding the counter argument "you need a transpolar anyway".

That's been the case since ES2015 landed with breaking syntax that has been required mandatory transpilation to keep it backward compatible, with things also not really transpilble such as classes with built-in extends ability.

Why suddenly the "need to transpile" is considered a point against any new JS feature? Are we already done with JS, if that's the case?

TypeScript exists and it has its own problems, 'cause its slightly diversions from what's defined via TC39 causes just confusion (i.e. private fields, to name one, built-in extends still broken if you target ES5, while Babel 7 fixed that, and template literals behave differently too - Babel 7 is the only one producing a standard behavior)

On top of that, many things recently landed in JS has been inspired by CoffeeScript ... where was the "just use CoffeeScript" argument at that time? Transpilers were already a thing then too.

Moreover ...

> the real value of strict types, in my view, is at development time, not at run time.

This is not correct. Check what AssemblyScript managed to do via types, targeting WASM instead of non-typed JS

If TypeScript, with its quirks, will be the language that help developers and win JS in the WASM field, we can start considering JS a second class citizen of the Web (and soon of the backend too, see deno).

Is this where we are with JS?

> I would be curious to know if anybody has a usage for them at run time

Developers might not have such usage, but V8 / Chackra / JSC / SpiderMonkey might spin up optimizations ahead of time, enabling right away hot code.

> a "toolchain" that allows strict typing using JavaScript without having to "use TypeScript".

even if it'll end up being identical or redundant, but I doubt it, for many companies/teams the least third parts dependencies you have the better is for code reliability.

I personally don't trust TS because it breaks when it targets ES5 and I cannot control what other people target, but I would trust the standard path and tools aiming at all cost to trample it right, whenever transpiring is needed.

With Edge moving to use Chrome, and Firefox and WebKit always catching up, these days introducing anything new might need transpilers just for a couple of years, instead of decades.

Best Regards





On Mon, Mar 25, 2019 at 9:55 AM Naveen Chawla <[hidden email]> wrote:
Yes the real value of strict types, in my view, is at development time, not at run time.

However I would be curious to know if anybody has a usage for them at run time, and an example of such a case...

Otherwise, yes a "toolchain" that allows strict typing using JavaScript without having to "use TypeScript".

On Mon, 25 Mar 2019 at 04:58, Ranando King <[hidden email]> wrote:
One thing is definitively true. Any static type system added to ES must not be mandatory. Untyped code must be able to call typed code without forcing references into a fixed type. Likewise, typed code must be able to call untyped code without forcing references to give up type guarantees.

On Sun, Mar 24, 2019 at 8:48 PM kai zhu <[hidden email]> wrote:
i share a similar concern that static-typing makes little sense in high-churn-rate UX-workflow-programming.

it encourage people to bikeshed for correctness, on low-level code that frequently gets rewritten every few weeks/months -- and with often demoralizing effects.

> On 24 Mar 2019, at 17:26, Bergi <[hidden email]> wrote:
>
> Hello,
> to play the devils advocate: why does JavaScript need static typing?
>
> Your proposal doesn't really answer that. Sure, it mentions tooling and
> IDEs that can provide you with type hints and complain on mistakes, but
> things like Flow and Typescript do this today already.
> What's your goal, to have JS engines run Typescript(-like) code natively
> without transpiling? For backwards-compatibility you'd have to do that
> anyway, especially if new type system features are introduced incrementally.
>
> What's the point of building this feature into engines? It just provides
> additional complexity. Not to mention the difficulty of finding a
> suitable type system that is both sophisticated enough to describe all
> useful code (not taking away too much flexibility) and simple enough to
> understand without a CS degree. And which interfaces well with un-typed
> completely dynamic code.
>
> What does "static typing" even mean to you in a dynamic scripting
> language? JavaScript is not compiled by the developer, it is run by the
> user. Where (when) do you expect types to be checked? Should the engine
> throw early errors (during parsing)? During parsing of which parts of
> the code, even when "normal" (untyped) code is calling into typed code?
> Or do you expect dynamic runtime errors, like when assigning an invalid
> value to a "typed variable" or calling a "typed function" with wrong
> arguments? Are type definitions completely constant or could they be
> mutated/extended/etc dynamically (and what happens when you introduce
> new types with `eval` or by loading another script)?
>
> A proposal would need to provide an objective that answers all these
> questions, before even considering any particular type system or syntax.
>
> One way to go forward that I can see would be a proposal that reserves a
> relatively unrestricted syntax for type annotations (which are already
> considered during every grammar amendment anyway, for compatibility with
> Flow/Typescript), but not assign any semantics to them and require
> engines to simply ignore them. External tooling could then use these
> annotations according to its own rules.
>
> kind regards,
> Bergi
> _______________________________________________
> 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
_______________________________________________
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

Bergi
In reply to this post by Andrea Giammarchi-2
Hi,

> I am having hard time understanding the counter argument "you need a
> transpiler anyway".

Sorry, I agree it's a bad argument, I should have just omitted it.
It was meant to support "If you are only looking for development-time
benefits, you have to install a static toolchain anyway - which might as
well transpile away the annotations".

>> the real value of strict types, in my view, is at development time,
> not at run time.
>
> This is not correct. Check what AssemblyScript managed to do via types,
> targeting WASM instead of non-typed JS
>
>> I would be curious to know if anybody has a usage for them at run time
>
> Developers might not have such usage, but V8 / Chakra / JSC /
> SpiderMonkey might spin up optimizations ahead of time, enabling right
> away hot code.

...or at least allow throwing exceptions instead of having to
de-optimise a JITted code, which allows simpler & better optimisation
algorithms.

These are the kinds of arguments I want to hear, reasons for sending
type annotations to the client/runtime. And such a goal puts a very
different focus on what the type system should look like: WASM
interoperability and optimiser efficiency instead of developer productivity.

kind regards,
  Bergi
_______________________________________________
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
> WASM interoperability and optimiser efficiency instead of developer productivity.

I've personally always seen types useful **only** for typed languages interoperability and/or optimization/performance hints to engines/runtimes, but since many developers apparently experience some productivity boost though typed languages oriented tools, why not having all the three checked?
  • WASM interoperability (a TC39 effort)
  • more efficient runtime (a runtime/engine effort)
  • boosted productivity (a third parts tools effort)
That doesn't look too bad to me, as possible JS' future.

Regards


On Mon, Mar 25, 2019 at 11:19 AM Bergi <[hidden email]> wrote:
Hi,

> I am having hard time understanding the counter argument "you need a
> transpiler anyway".

Sorry, I agree it's a bad argument, I should have just omitted it.
It was meant to support "If you are only looking for development-time
benefits, you have to install a static toolchain anyway - which might as
well transpile away the annotations".

>> the real value of strict types, in my view, is at development time,
> not at run time.
>
> This is not correct. Check what AssemblyScript managed to do via types,
> targeting WASM instead of non-typed JS
>
>> I would be curious to know if anybody has a usage for them at run time
>
> Developers might not have such usage, but V8 / Chakra / JSC /
> SpiderMonkey might spin up optimizations ahead of time, enabling right
> away hot code.

...or at least allow throwing exceptions instead of having to
de-optimise a JITted code, which allows simpler & better optimisation
algorithms.

These are the kinds of arguments I want to hear, reasons for sending
type annotations to the client/runtime. And such a goal puts a very
different focus on what the type system should look like: WASM
interoperability and optimiser efficiency instead of developer productivity.

kind regards,
  Bergi
_______________________________________________
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
* trough (geeeeeeeez)

On Mon, Mar 25, 2019 at 11:41 AM Andrea Giammarchi <[hidden email]> wrote:
> WASM interoperability and optimiser efficiency instead of developer productivity.

I've personally always seen types useful **only** for typed languages interoperability and/or optimization/performance hints to engines/runtimes, but since many developers apparently experience some productivity boost though typed languages oriented tools, why not having all the three checked?
  • WASM interoperability (a TC39 effort)
  • more efficient runtime (a runtime/engine effort)
  • boosted productivity (a third parts tools effort)
That doesn't look too bad to me, as possible JS' future.

Regards


On Mon, Mar 25, 2019 at 11:19 AM Bergi <[hidden email]> wrote:
Hi,

> I am having hard time understanding the counter argument "you need a
> transpiler anyway".

Sorry, I agree it's a bad argument, I should have just omitted it.
It was meant to support "If you are only looking for development-time
benefits, you have to install a static toolchain anyway - which might as
well transpile away the annotations".

>> the real value of strict types, in my view, is at development time,
> not at run time.
>
> This is not correct. Check what AssemblyScript managed to do via types,
> targeting WASM instead of non-typed JS
>
>> I would be curious to know if anybody has a usage for them at run time
>
> Developers might not have such usage, but V8 / Chakra / JSC /
> SpiderMonkey might spin up optimizations ahead of time, enabling right
> away hot code.

...or at least allow throwing exceptions instead of having to
de-optimise a JITted code, which allows simpler & better optimisation
algorithms.

These are the kinds of arguments I want to hear, reasons for sending
type annotations to the client/runtime. And such a goal puts a very
different focus on what the type system should look like: WASM
interoperability and optimiser efficiency instead of developer productivity.

kind regards,
  Bergi
_______________________________________________
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: Re: Proposal: Static Typing

ViliusCreator
In reply to this post by ViliusCreator

> Hello, to play the devils advocate: why does JavaScript need static typing? Your proposal doesn't really answer that. Sure, it mentions tooling and IDEs that can provide you with type hints and complain on mistakes

I actually did. It keeps unwanted type mutations and bad values away. For example,

This:

```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.

```

This can help developer itself, in runtime, not only at development time. “But IDE wouldn’t allow that.” But what if property in required json(node js), is undefined? Some IDEs don’t have JSON intellisense, so this is where it can get annoying.

> but things like Flow and Typescript do this today already. 

Yes, but they are compile-time only. Meaning, that in runtime, type mutation and unwanted values can happen.

> What's your goal, to have JS engines run Typescript(-like) code natively without transpiling?

First of, this is compiling. TypeScript is higher level than JS, so it’s compiling. Second, TypeScript code is completely compile-time only. Classes(And other ES8+ code), imports, exports and probably namespaces are the only things which are at runtime also.

> What's the point of building this feature into engines? It just provides additional complexity.

I said reasons above. Also as I said, they are optional. Meaning, new comers can still learn old js code without static types. Besides, doesn’t async, await, classes and other new stuff add complexity to new people to JS?

> Where (when) do you expect types to be checked? Should the engine throw early errors (during parsing)?

Languages normally check types during compile-time. I expect JS to throw errors in runtime, meaning that if you make code which would throw type error and it’s untouched, then it doesn’t throw an error.

> What does "static typing" even mean to you in a dynamic scripting language?

Same thing as in real statically typed languages. Type checking.

> and what happens when you introduce new types with `eval` or by loading another script?

Since as I said, they are runtime only type checking.

 

> However I would be curious to know if anybody has a usage for them at run time

They have. `eval` can make type mutation(and if it checks the string, you can still overcome them(inputs or array joining)).

 

Also, if transpiling and compiling is better, why not leave JS dead? I mean, compilers can do job instead of JS. It’s just basically useless, compilers can do awesome stuff, so “no need for new features in JS”(and then if we did, wasm would take over in web development, or browsers would overcome ES and use something else instead).


Virus-free. www.avast.com

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

Re: Re: Proposal: Static Typing

guest271314


```js

let a: number = 10

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

What if  

```"101"```

is the expected result?


Would  

Strict mode for scripts

> To invoke strict mode for an entire script, put the exact statement ```"use strict";``` (or ```'use strict';```) before any other statements.

```"use static typing"```

suffice?




On Mon, Mar 25, 2019 at 5:13 PM ViliusCreator <[hidden email]> wrote:

> Hello, to play the devils advocate: why does JavaScript need static typing? Your proposal doesn't really answer that. Sure, it mentions tooling and IDEs that can provide you with type hints and complain on mistakes

I actually did. It keeps unwanted type mutations and bad values away. For example,

This:

```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.

```

This can help developer itself, in runtime, not only at development time. “But IDE wouldn’t allow that.” But what if property in required json(node js), is undefined? Some IDEs don’t have JSON intellisense, so this is where it can get annoying.

> but things like Flow and Typescript do this today already. 

Yes, but they are compile-time only. Meaning, that in runtime, type mutation and unwanted values can happen.

> What's your goal, to have JS engines run Typescript(-like) code natively without transpiling?

First of, this is compiling. TypeScript is higher level than JS, so it’s compiling. Second, TypeScript code is completely compile-time only. Classes(And other ES8+ code), imports, exports and probably namespaces are the only things which are at runtime also.

> What's the point of building this feature into engines? It just provides additional complexity.

I said reasons above. Also as I said, they are optional. Meaning, new comers can still learn old js code without static types. Besides, doesn’t async, await, classes and other new stuff add complexity to new people to JS?

> Where (when) do you expect types to be checked? Should the engine throw early errors (during parsing)?

Languages normally check types during compile-time. I expect JS to throw errors in runtime, meaning that if you make code which would throw type error and it’s untouched, then it doesn’t throw an error.

> What does "static typing" even mean to you in a dynamic scripting language?

Same thing as in real statically typed languages. Type checking.

> and what happens when you introduce new types with `eval` or by loading another script?

Since as I said, they are runtime only type checking.

 

> However I would be curious to know if anybody has a usage for them at run time

They have. `eval` can make type mutation(and if it checks the string, you can still overcome them(inputs or array joining)).

 

Also, if transpiling and compiling is better, why not leave JS dead? I mean, compilers can do job instead of JS. It’s just basically useless, compilers can do awesome stuff, so “no need for new features in JS”(and then if we did, wasm would take over in web development, or browsers would overcome ES and use something else instead).


Virus-free. www.avast.com
_______________________________________________
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

Randy Buchholz
In reply to this post by ViliusCreator

I recently started doing a lot of ES, coming from C# and really missed “typings” at first. But once I learned to think more in es,  they became less necessary – even cumbersome in some ways. The question for me on this really comes down to what is a ”type” and what value does it bring. As I see it, a type is a structural contract, in the same way an interface is a behavioral contract. The value of contracts is that they minimize the need to trust. I.e., if I pass a known-type to a function, I can know that it will have a specific structure (e.g., known properties and methods in a class).  Without types, I must trust or check the structure. But, types aren’t really self-aware. It is the environment that enforces types. Once you have types, you must have what I call a “Type Authority”. Built-in types are always known by the authority, and when you declare a type,  you are adding to what the authority knows. The authority can look at the code and do the “checking” of what is passed based on what it knows. Having types lets me not have to trust in what I am receiving – it can be verified for me.

 

In a compiled language, types provide “hidden” value. The compiler can look at the entire code based and make optimization decisions around types (e.g., in-lining). In a dynamic, interpreted language, (for the most part) this doesn’t happen. Types must be processed at each point of use. So, the value of types stays mostly limited to knowing the structure. Which is though, extremely useful. The problem with static types, is that they exist at the wrong place in time. A static type is a design-time constraint. Yet the environment doesn’t really know about the type until each run-time use. This puts unnecessary limits on the language – adding a property at run-time (while scary at first) is one of my favorite features of the language. Static typing adds other layers of complexity – like namespaces. Locking down a type at design-time essentially “hijacks” a name. A static type “Person” must be consistent across the entire application environment. In uses like Web, where it is common to pull code from many remote sources and libraries,  how does “Person” remain “static” across these?

 

I would propose an alternative to static typing – the Type Authority. The Type Authority is a architecture component that (among other things) provides “scoped/run-time statics”. Essentially, the Type Authority is an application-wide dynamic repository of types, in the run-time environment. This opt-in feature would allow dynamically creating types, and then making them “fixed” them with application scope. Once registered, the type is basically static. Using a hierarchal approach and “dotted” naming notation, (e.g., library.component.typename) types can be localized or extended. For example, a library can be imported, and types given a “namespace prefix”. The qualified name would effectively be a static type within the application context. Properties could be dynamically added, and the new type registered as a ”child type” (e.g., Person => Person.Domain). This would then allow casting - (Person)DomainPersonInstance. A simple Type Authority would support basic “is a”/”typeof” capabilities. A more advanced system could provide factory methods.

 

This approach provides a way to enforce the structural contract nature of types, while retaining the dynamic nature of the language.


_______________________________________________
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
Doesn't V8 already use such a concept to manage optimization? When a reference's structure mutates, V8 generates a new type by extending the previous one with the changes, then kills any affected optimizations around the mutated object, forcing re-optimization. Static types would essentially provide a guarantee that such re-optimizations would be completely unnecessary for the lifetime of the object since it would be impossible to mutate the object's structure. It would also allow for early optimization since the structure would already be known. These are the benefits of static typing. It's not just a matter of developer trust but also engine efficiency.

On Tue, Mar 26, 2019 at 12:21 AM Randy Buchholz <[hidden email]> wrote:

I recently started doing a lot of ES, coming from C# and really missed “typings” at first. But once I learned to think more in es,  they became less necessary – even cumbersome in some ways. The question for me on this really comes down to what is a ”type” and what value does it bring. As I see it, a type is a structural contract, in the same way an interface is a behavioral contract. The value of contracts is that they minimize the need to trust. I.e., if I pass a known-type to a function, I can know that it will have a specific structure (e.g., known properties and methods in a class).  Without types, I must trust or check the structure. But, types aren’t really self-aware. It is the environment that enforces types. Once you have types, you must have what I call a “Type Authority”. Built-in types are always known by the authority, and when you declare a type,  you are adding to what the authority knows. The authority can look at the code and do the “checking” of what is passed based on what it knows. Having types lets me not have to trust in what I am receiving – it can be verified for me.

 

In a compiled language, types provide “hidden” value. The compiler can look at the entire code based and make optimization decisions around types (e.g., in-lining). In a dynamic, interpreted language, (for the most part) this doesn’t happen. Types must be processed at each point of use. So, the value of types stays mostly limited to knowing the structure. Which is though, extremely useful. The problem with static types, is that they exist at the wrong place in time. A static type is a design-time constraint. Yet the environment doesn’t really know about the type until each run-time use. This puts unnecessary limits on the language – adding a property at run-time (while scary at first) is one of my favorite features of the language. Static typing adds other layers of complexity – like namespaces. Locking down a type at design-time essentially “hijacks” a name. A static type “Person” must be consistent across the entire application environment. In uses like Web, where it is common to pull code from many remote sources and libraries,  how does “Person” remain “static” across these?

 

I would propose an alternative to static typing – the Type Authority. The Type Authority is a architecture component that (among other things) provides “scoped/run-time statics”. Essentially, the Type Authority is an application-wide dynamic repository of types, in the run-time environment. This opt-in feature would allow dynamically creating types, and then making them “fixed” them with application scope. Once registered, the type is basically static. Using a hierarchal approach and “dotted” naming notation, (e.g., library.component.typename) types can be localized or extended. For example, a library can be imported, and types given a “namespace prefix”. The qualified name would effectively be a static type within the application context. Properties could be dynamically added, and the new type registered as a ”child type” (e.g., Person => Person.Domain). This would then allow casting - (Person)DomainPersonInstance. A simple Type Authority would support basic “is a”/”typeof” capabilities. A more advanced system could provide factory methods.

 

This approach provides a way to enforce the structural contract nature of types, while retaining the dynamic nature of the language.

_______________________________________________
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

Dan Peddle
It's really a shame few mention jsdoc anymore. It provides mechanisms to achieve all of these developer experience quality of life improvements without needing transpiling, and on top of standard js of various flavours, progressively.


On 26. Mar 2019, at 06:43, Ranando King <[hidden email]> wrote:

Doesn't V8 already use such a concept to manage optimization? When a reference's structure mutates, V8 generates a new type by extending the previous one with the changes, then kills any affected optimizations around the mutated object, forcing re-optimization. Static types would essentially provide a guarantee that such re-optimizations would be completely unnecessary for the lifetime of the object since it would be impossible to mutate the object's structure. It would also allow for early optimization since the structure would already be known. These are the benefits of static typing. It's not just a matter of developer trust but also engine efficiency.

On Tue, Mar 26, 2019 at 12:21 AM Randy Buchholz <[hidden email]> wrote:

I recently started doing a lot of ES, coming from C# and really missed “typings” at first. But once I learned to think more in es,  they became less necessary – even cumbersome in some ways. The question for me on this really comes down to what is a ”type” and what value does it bring. As I see it, a type is a structural contract, in the same way an interface is a behavioral contract. The value of contracts is that they minimize the need to trust. I.e., if I pass a known-type to a function, I can know that it will have a specific structure (e.g., known properties and methods in a class).  Without types, I must trust or check the structure. But, types aren’t really self-aware. It is the environment that enforces types. Once you have types, you must have what I call a “Type Authority”. Built-in types are always known by the authority, and when you declare a type,  you are adding to what the authority knows. The authority can look at the code and do the “checking” of what is passed based on what it knows. Having types lets me not have to trust in what I am receiving – it can be verified for me.

 

In a compiled language, types provide “hidden” value. The compiler can look at the entire code based and make optimization decisions around types (e.g., in-lining). In a dynamic, interpreted language, (for the most part) this doesn’t happen. Types must be processed at each point of use. So, the value of types stays mostly limited to knowing the structure. Which is though, extremely useful. The problem with static types, is that they exist at the wrong place in time. A static type is a design-time constraint. Yet the environment doesn’t really know about the type until each run-time use. This puts unnecessary limits on the language – adding a property at run-time (while scary at first) is one of my favorite features of the language. Static typing adds other layers of complexity – like namespaces. Locking down a type at design-time essentially “hijacks” a name. A static type “Person” must be consistent across the entire application environment. In uses like Web, where it is common to pull code from many remote sources and libraries,  how does “Person” remain “static” across these?

 

I would propose an alternative to static typing – the Type Authority. The Type Authority is a architecture component that (among other things) provides “scoped/run-time statics”. Essentially, the Type Authority is an application-wide dynamic repository of types, in the run-time environment. This opt-in feature would allow dynamically creating types, and then making them “fixed” them with application scope. Once registered, the type is basically static. Using a hierarchal approach and “dotted” naming notation, (e.g., library.component.typename) types can be localized or extended. For example, a library can be imported, and types given a “namespace prefix”. The qualified name would effectively be a static type within the application context. Properties could be dynamically added, and the new type registered as a ”child type” (e.g., Person => Person.Domain). This would then allow casting - (Person)DomainPersonInstance. A simple Type Authority would support basic “is a”/”typeof” capabilities. A more advanced system could provide factory methods.

 

This approach provides a way to enforce the structural contract nature of types, while retaining the dynamic nature of the language.

_______________________________________________
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
jsdoc doesn't exist in production so it cannot provide any info to the runtime, making WASM interoperability and hot code optimizations impossible.

Let's please keep the discussion focused on the achievements current JS cannot possibly have, thanks.



On Tue, Mar 26, 2019 at 9:06 AM Dan Peddle <[hidden email]> wrote:
It's really a shame few mention jsdoc anymore. It provides mechanisms to achieve all of these developer experience quality of life improvements without needing transpiling, and on top of standard js of various flavours, progressively.


On 26. Mar 2019, at 06:43, Ranando King <[hidden email]> wrote:

Doesn't V8 already use such a concept to manage optimization? When a reference's structure mutates, V8 generates a new type by extending the previous one with the changes, then kills any affected optimizations around the mutated object, forcing re-optimization. Static types would essentially provide a guarantee that such re-optimizations would be completely unnecessary for the lifetime of the object since it would be impossible to mutate the object's structure. It would also allow for early optimization since the structure would already be known. These are the benefits of static typing. It's not just a matter of developer trust but also engine efficiency.

On Tue, Mar 26, 2019 at 12:21 AM Randy Buchholz <[hidden email]> wrote:

I recently started doing a lot of ES, coming from C# and really missed “typings” at first. But once I learned to think more in es,  they became less necessary – even cumbersome in some ways. The question for me on this really comes down to what is a ”type” and what value does it bring. As I see it, a type is a structural contract, in the same way an interface is a behavioral contract. The value of contracts is that they minimize the need to trust. I.e., if I pass a known-type to a function, I can know that it will have a specific structure (e.g., known properties and methods in a class).  Without types, I must trust or check the structure. But, types aren’t really self-aware. It is the environment that enforces types. Once you have types, you must have what I call a “Type Authority”. Built-in types are always known by the authority, and when you declare a type,  you are adding to what the authority knows. The authority can look at the code and do the “checking” of what is passed based on what it knows. Having types lets me not have to trust in what I am receiving – it can be verified for me.

 

In a compiled language, types provide “hidden” value. The compiler can look at the entire code based and make optimization decisions around types (e.g., in-lining). In a dynamic, interpreted language, (for the most part) this doesn’t happen. Types must be processed at each point of use. So, the value of types stays mostly limited to knowing the structure. Which is though, extremely useful. The problem with static types, is that they exist at the wrong place in time. A static type is a design-time constraint. Yet the environment doesn’t really know about the type until each run-time use. This puts unnecessary limits on the language – adding a property at run-time (while scary at first) is one of my favorite features of the language. Static typing adds other layers of complexity – like namespaces. Locking down a type at design-time essentially “hijacks” a name. A static type “Person” must be consistent across the entire application environment. In uses like Web, where it is common to pull code from many remote sources and libraries,  how does “Person” remain “static” across these?

 

I would propose an alternative to static typing – the Type Authority. The Type Authority is a architecture component that (among other things) provides “scoped/run-time statics”. Essentially, the Type Authority is an application-wide dynamic repository of types, in the run-time environment. This opt-in feature would allow dynamically creating types, and then making them “fixed” them with application scope. Once registered, the type is basically static. Using a hierarchal approach and “dotted” naming notation, (e.g., library.component.typename) types can be localized or extended. For example, a library can be imported, and types given a “namespace prefix”. The qualified name would effectively be a static type within the application context. Properties could be dynamically added, and the new type registered as a ”child type” (e.g., Person => Person.Domain). This would then allow casting - (Person)DomainPersonInstance. A simple Type Authority would support basic “is a”/”typeof” capabilities. A more advanced system could provide factory methods.

 

This approach provides a way to enforce the structural contract nature of types, while retaining the dynamic nature of the language.

_______________________________________________
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

_______________________________________________
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
Actually, on that very same note, since WASM <-> JS might be the only reason, or likely the best one, to have types in JS, let's consider from scratch all WASM types as possible primitives to adopt, shall we?

i32 (alias as int?)
i64
f32 (alias as float?)
f64
u32 (alias uint?)

then we have functype (function) limits (dynamic arrays) memory (static arrays) and tables (objects/maps) to deal with, plus global and external.

If we find a syntax to represent these types, targeting, or consuming in an optimized way, WASM, might be a reality, with better results than asm.js, since that's very hard to write / remember for humans, IMO.

I also would like to know the opinion of someone close to V8 or other engines.

Regards







On Tue, Mar 26, 2019 at 10:03 AM Andrea Giammarchi <[hidden email]> wrote:
jsdoc doesn't exist in production so it cannot provide any info to the runtime, making WASM interoperability and hot code optimizations impossible.

Let's please keep the discussion focused on the achievements current JS cannot possibly have, thanks.



On Tue, Mar 26, 2019 at 9:06 AM Dan Peddle <[hidden email]> wrote:
It's really a shame few mention jsdoc anymore. It provides mechanisms to achieve all of these developer experience quality of life improvements without needing transpiling, and on top of standard js of various flavours, progressively.


On 26. Mar 2019, at 06:43, Ranando King <[hidden email]> wrote:

Doesn't V8 already use such a concept to manage optimization? When a reference's structure mutates, V8 generates a new type by extending the previous one with the changes, then kills any affected optimizations around the mutated object, forcing re-optimization. Static types would essentially provide a guarantee that such re-optimizations would be completely unnecessary for the lifetime of the object since it would be impossible to mutate the object's structure. It would also allow for early optimization since the structure would already be known. These are the benefits of static typing. It's not just a matter of developer trust but also engine efficiency.

On Tue, Mar 26, 2019 at 12:21 AM Randy Buchholz <[hidden email]> wrote:

I recently started doing a lot of ES, coming from C# and really missed “typings” at first. But once I learned to think more in es,  they became less necessary – even cumbersome in some ways. The question for me on this really comes down to what is a ”type” and what value does it bring. As I see it, a type is a structural contract, in the same way an interface is a behavioral contract. The value of contracts is that they minimize the need to trust. I.e., if I pass a known-type to a function, I can know that it will have a specific structure (e.g., known properties and methods in a class).  Without types, I must trust or check the structure. But, types aren’t really self-aware. It is the environment that enforces types. Once you have types, you must have what I call a “Type Authority”. Built-in types are always known by the authority, and when you declare a type,  you are adding to what the authority knows. The authority can look at the code and do the “checking” of what is passed based on what it knows. Having types lets me not have to trust in what I am receiving – it can be verified for me.

 

In a compiled language, types provide “hidden” value. The compiler can look at the entire code based and make optimization decisions around types (e.g., in-lining). In a dynamic, interpreted language, (for the most part) this doesn’t happen. Types must be processed at each point of use. So, the value of types stays mostly limited to knowing the structure. Which is though, extremely useful. The problem with static types, is that they exist at the wrong place in time. A static type is a design-time constraint. Yet the environment doesn’t really know about the type until each run-time use. This puts unnecessary limits on the language – adding a property at run-time (while scary at first) is one of my favorite features of the language. Static typing adds other layers of complexity – like namespaces. Locking down a type at design-time essentially “hijacks” a name. A static type “Person” must be consistent across the entire application environment. In uses like Web, where it is common to pull code from many remote sources and libraries,  how does “Person” remain “static” across these?

 

I would propose an alternative to static typing – the Type Authority. The Type Authority is a architecture component that (among other things) provides “scoped/run-time statics”. Essentially, the Type Authority is an application-wide dynamic repository of types, in the run-time environment. This opt-in feature would allow dynamically creating types, and then making them “fixed” them with application scope. Once registered, the type is basically static. Using a hierarchal approach and “dotted” naming notation, (e.g., library.component.typename) types can be localized or extended. For example, a library can be imported, and types given a “namespace prefix”. The qualified name would effectively be a static type within the application context. Properties could be dynamically added, and the new type registered as a ”child type” (e.g., Person => Person.Domain). This would then allow casting - (Person)DomainPersonInstance. A simple Type Authority would support basic “is a”/”typeof” capabilities. A more advanced system could provide factory methods.

 

This approach provides a way to enforce the structural contract nature of types, while retaining the dynamic nature of the language.

_______________________________________________
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

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