Proposal: Static Typing
naveen.chwl at gmail.com
Mon Mar 25 08:55:27 UTC 2019
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...
without having to "use TypeScript".
On Mon, 25 Mar 2019 at 04:58, Ranando King <kingmph at gmail.com> 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 <kaizhu256 at gmail.com> 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 <a.d.bergi at web.de> wrote:
>> > Hello,
>> > 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
>> > 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
>> > 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
>> > es-discuss at mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>> es-discuss mailing list
>> es-discuss at mozilla.org
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss