Proposal: Static Typing

Ranando King kingmph at gmail.com
Mon Mar 25 04:58:44 UTC 2019


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,
> > 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
> > 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/20190324/75ec124a/attachment.html>


More information about the es-discuss mailing list