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

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

# John Lenz (8 years ago)

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.

# Kris Siegel (8 years ago)

I love this idea. I was originally hoping to champion a whole slew of additions to the JavaScript Standard Library because I'd really love for a set of standard ways to do much of what we use private APIs today (lack of time to follow up on my original thread).

I'm not sure how it works out logistically though with ECMA. But a separation at least makes sense to me (especially if we start adding a lot to the standard library which I know many are against but like Python I think it would be a huge boon to the JavaScript community).

I don't think import foo from std is the worst idea either but that would be breaking unless we put it under "use stricter" or something similar.

# Isiah Meadows (8 years ago)

@Kris What about import {apply} from "@std:reflect"? (totally not my original idea)