Proposal: Splitting the "Standard Library" from the EcmaScript spec

[John Lenz]

A fair amount of text in the EcmaScript spec is spent on defining the
EcmaScript standard classes and methods.  This has the side-effect of doing
two things:

  - encouraging standard classes/methods to have special behavior
  - discouraging creating appropriate "building blocks"

How differently would EcmaScript have been defined if Map, WeakMap,
Promise, etc were only defined in terms of a "core" language.   Would we
have a standard identity hash code? A concept of time?

Many of the existing Array.prototype methods, etc could be moved to
"Library" project that could be defined in terms of an implementation
rather than step-by-step spec language.

To be clear, I'm not proposing a different delivery mechanism (aka "import
foo from std") but simply a change to the evolutionary process to encourage
a clean separation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160728/d02134db/attachment.html>