Optional Static Typing (Part 2)

[Michał Wadas]

This strawman have a lot of issues.

   - Changing behavior of typeof would probably break the web or cause big
   troubles (eg. "we can't upgrade library because new objects break our
   typeof checks").
   - Including special types like "uint32" is MUCH bigger task than
   including optional typing - we need to get types first, then include
   compile time type checks
   - Typed exceptions are inferior to more flexible exception filters
   - Your type system is primitive - it's support for functions is almost
   non-existant (what is your type annotation for foo:uint32 => bar:float32
   => anno:string => `${anno} = ${foo+bar}), unions, intersection types,
   this type, interfaces.
   - "use stricter" - it's out of scope of optional static typing
   - Multiple dispatch in dynamic language is much bigger problem than one
   section paragraph.


On Sun, Jul 17, 2016 at 6:20 AM, Brandon Andrews <
warcraftthreeft at sbcglobal.net> wrote:

> I've been very slowly expanding a proposal that I started 1 year ago. The
> current proposal and links to the previous discussion is here:
>
>
> https://github.com/sirisian/ecmascript-types (If the link gets truncated
> by esdiscuss.org because of the hyphen view the source to see it).
>
>
> Since a year ago I've read through the current specification partially
> analyzing key pieces that would need to be modified, have their wording
> changed, or that would need to be discussed for static typing to happen. In
> that effort I've spoken to a lot of developers about certain features,
> preferences, use cases, and where others want the language to head. I'd
> rather not see this post devolve into discussions about how TypeScript,
> CoffeeScript, or WebAssembly exist. I've seen many people try to discuss
> those as reasons to not evolve ECMAScript, but as has been mentioned before
> the language is expected to continue to exist and evolve separate from them.
>
>
> What I would like from the ECMAScript community is anyone that wants to
> discuss specification issues or expansions to the current proposal.
> Basically the current pool of people I've been talking to think I've
> covered the key pieces they wanted to see. If anyone here is interested in
> the subject and wants to create issues on the github or pull requests to
> expand sections I'd appreciate it. I'm also looking for anyone that has
> more intimate knowledge about the grammar. I've been working my way through
> the grammar, but it's a very daunting and time consuming task for me to
> create the extra grammar rules or analyze conflicts. Anyone that's done
> that in the past and would be willing to help it would help the proposal a
> lot.
>
> Also since I've been asked before, when all the specification sections and
> grammar are done I'll look for a champion. It's too risky to present a type
> proposal without first considering everything which is why the proposal
> needs feedback and work.
> _______________________________________________
> 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/20160717/ec678416/attachment.html>