Skip to content

Instantly share code, notes, and snippets.

Daniel Ehrenberg littledan

Block or report user

Report or block littledan

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
View test262-babel-getting-started.sh
npm install -g test262-harness
npm install -g babel-cli
npm install -g jsvu
jsvu
git clone https://github.com/tc39/test262.git
test262-harness --test262Dir test262 --babelPresets stage-3 --hostType d8 --hostPath ~/.jsvu/v8 test262/test/intl402/*
@littledan
littledan / gist:cdee21a5782b9169e0844f6c94e30204
Created Apr 10, 2018
WebAssembly spec compatibility issues
View gist:cdee21a5782b9169e0844f6c94e30204
A summary of the issues for WebAssembly that Dan has been thinking about:
- CSP -- https://github.com/WebAssembly/content-security-policy/pull/13
- When the checks happen
- What the checks are
- Resource limits -- https://github.com/WebAssembly/spec/issues/607
- Should we align resource limits?
- How should the limit on local variables be interpreted?
- What are the magic numbers? (These have already had to rise due to lack of implementation)
- Memory objects limit -- do we have consensus that there should be no limit? https://github.com/WebAssembly/design/issues/1167
View operator-overloading.js
class Vec {
#x;
#y;
#z;
constructor(x, y, z) {
this.#x = x;
this.#y = y;
this.#z = z;
}
View lexical-friends.js
// In the following code, take `private` and `friend` to be extremely early strawperson names
private #x; // Declare a private name
let obj = { outer #x: 1 };
class MyClass {
outer #x;
constructor(x) { this.#x = x }
}
@littledan
littledan / header.jsidl
Created Dec 4, 2017
Should JavaScript use a header file format (a la WebIDL) to define its standard library?
View header.jsidl
@namespace
class Math {
static abs(x: Number): Number; // Types optional; provide cast on input and assertion on ouptut
@nonwritable
static LOG10E: Number;
// ...
}
@littledan
littledan / tc39-pr-process-doc.md
Last active Sep 27, 2017
Proposed TC39 pull request process document
View tc39-pr-process-doc.md

TC39 accepts changes through two processes--the four-stage proposal process and pull requests. Staged proposals are governed by the process document, whereas pull requests are lighter-weight, working through informal rules and conventions, as administered by the editor. This document attempts to codify a process for pull requests, mostly through writing down current practice (to help others follow along what's happening, and to help the next editor if there is a transition), but a change from current practice is included in bold.

Algorithm for getting a PR merged:

  1. If the PR is purely editorial or to support layering, tag it as 'editorial' or 'layering'.
  2. Otherwise, tag it as 'normative', as it makes an observable semantic change.
  3. If the PR is about reflecting what some web browsers' behavior is, tag it as 'web reality'.
  4. Get consensus on the PR. If this is difficult or time-consuming, mark 'needs consensus' as it is gaining consensus.
  5. If the PR is tagge
View silly-promise-bench.js
var resolve;
var promise = new Promise(r => resolve = r);
async function foo(i) {
if (i > 100000) return promise;
return foo(i+1);
}
foo(0);
resolve();
View zepto-issue.md

Zepto compatibility concerns

@@species came up on TC39's agenda in an attempt to preserve compatibility with Zepto. A patch was merged on October 21, 2014 to remove the problematic use of __proto__, but the old code can be found here. Here's the relevant snippet:

  zepto.Z = function(dom, selector) {
    dom = dom || []
    dom.__proto__ = $.fn
    dom.selector = selector || ''
    return dom
  }
View reconsidering-species.md

Reconsidering @@species

ES2015 added the @@species feature, where subclassing of builtins is enhanced by creating instances not of this.constructor but of this.constructor[Symbol.species]. There are a few issues with @@species:

  • @@species is called in some places but not others in a way that feels a bit inconsistent (from instance methods but not static methods). See bugs 1 2 (Kevin Smith)
  • @@species feels a bit unnecessary. It was motivated initially by ensuring Zepto's strange use of proto would continue to work. There's already an extension point by overwriting the constructor field, a simpler fix would have been possible, and Zepto was updated a year ago to not use these patterns.
  • @@species will be a lot of work to implement across standard libraries of all JS engines without a performance regression.

This document explo

View sloppy-function-hoisting-alt.md

In this proposed alternative to sloppy-mode function hoisting semantics, sloppy-mode FunctionDeclaration are always single var-style bindings. The var is set to the value of the function at the top of the block where the FunctionDeclaration occurs. I believe these semantics roughly match IE10 and earlier sloppy mode function hoisting semantics.

Goals

  • Maintain compatibility at the intersection of what browsers have supported for a long time
  • Support is self-defining functions defined in blocks (https://github.com/tc39/ecma262/issues/162)
  • If possible, be intelligible for users and implementors (simple semantics win out when they make sense)
  • Preserve strict-mode lexical scoping of FunctionDeclarations (this proposal only affects sloppy mode)

Non-goals

  • Make a lexical binding in sloppy mode, and generally try to make sloppy mode block-scoped FunctionDeclarations act like lexical bindings, including suppressing errors, when possible
You can’t perform that action at this time.