About this Directory

The harmony namespace is intended to contain approved proposals for the ES-Harmony language.

The following requirements, goals, and means help to inform and guide development of proposed extensions and improvements to ES5 for ES-Harmony.

Straw-man proposals live in strawman until approved by TC39, at which point they move into the harmony namespace, linked from the proposals page.

Working drafts of the specification for the next edition of ECMAScript that incorporates Harmony proposals is on the Specification Drafts page.

— Brendan Eich 2009/07/29 23:42

1. New features require concrete demonstrations.
2. Keep the language pleasant for casual developers.
3. Preserve the “start small and iteratively prototype” nature of the language.

1. Be a better language for writing:
   1. complex applications;
   2. libraries (possibly including the DOM) shared by those applications;
   3. code generators targeting the new edition.
2. Switch to a testable specification, ideally a definitional interpreter hosted mostly in ES5.
3. Improve interoperation, adopting de facto standards where possible.
4. Keep versioning as simple and linear as possible.
5. Support a statically verifiable, object-capability secure subset.

1. Minimize the additional semantic state needed beyond ES5.
2. Provide syntactic conveniences for:
   1. good abstraction patterns;
   2. high integrity patterns;
   3. defined by desugaring into kernel semantics.
3. Remove (via opt-in versioning or pragmas) confusing or troublesome constructs.
   1. Harmony builds on ES5 strict mode to avoid too many modes.
4. Support virtualizability, allowing for host object emulation.

1. Modularity, or how to delineate units of source code to hide the insides from outside users
2. Isolation, to prevent effects from propagating, or allow them only through certain references
   • Zero-authority maker-style modules
   • Other combinations of primordials/contexts/builtins with modules
   • Lack of isolation in browsers: multiple connected global objects
3. Virtualization, for stratified guest code hosting, bridging disjoint object systems, and in particular emulating host objects
   • Proxies
   • Weak references or Ephemerons
4. Control Effects, for simpler iteration and state-machine code
   • Delimited continuations
   • Generators, iterators
5. Library/Tool Enabling, so the TC39 committee is not blocking library evolution
   • Object.hashcode
   • Byte arrays of some kind
   • Value types (for Decimal, etc.).
6. Language Reform, the “better carrots” needed to lead users away from bad forms
   • let, const, function in block scope
   • Default and rest parameters, the spread operator
   • Destructuring
7. Versioning, since new syntax is part of Harmony.
   • This theme is about minimizing opt-in versioning, easing migration, and future-proofing for the next edition.