so ```
let c1 = Composite({wallet: amount: 20});
let c2 = Composite({wallet: amount: 20});
c1 === c2; // true
c1.wallet.amount+=20;
c1 === c2 // ??

But these would be the same:

let wallet = { amount: 20 };
let c1 = Composite({ wallet });
let c2 = Composite({ wallet });

"Khronos typed arrays" refers to the JavaScript Typed Arrays specification, which was originally developed under the Khronos Group for use in its graphics APIs like WebGL

(google ai summary)

specifically, for abort listeners added from web machinery instead of userland, you have these things:

• someone manually doing a dispatchEvent on the signal won't trigger your callback
• another listener doing stopImmediatePropagation won't prevent your callback from being triggered
• the callback is automatically released once the signal is aborted
• adding a callback after the signal is already aborted won't do anything (and in particular won't hold a reference to your callback)

users consumers of AbortSignal don't get any of those

My major concerns with AbortController are:

• Dependence on DOM-specific eventing/exceptions.
• DOM APIs privileged over user code
• Poor separation of concerns (user listeners for abort can be fooled by .dispatchEvent)
• No single use abort for user code (again, due to dispatchEvent)
• No cancellation graphs (somewhat addressed over the years, but not well), so memory leaks abound

bakkot:

I don't understand why the web platform uses a completely different set of infrastructure for abortables

Web specs never listen to events internally.

My proposal originally had something like:

class CancelSource {
  constructor(...linkedTokens: CancelToken[]);
  token: CancelToken;
  cancel(): void;
  close(): void;
}
class CancelToken {
  static canceled: CancelToken;
  static none: CancelToken;
  get canceled(): boolean;
  get canBeCanceled(): boolean;
  get reason(): unknown;
  subscribe(cb): CancelSubscription; // disposable
  throwIfCanceled(): void;
}

Imagine a .NET Task being something like:

function Task(init, opts) {
  if (opts?.delay) {
    const { promise, resolve, reject } = Promise.withResolvers();
    promise.start = () => init(resolve, reject);
    return promise;
  }  
  const p = new Promise(init);
  p.start = () => {};
  return p;
}

Moddable XS has a minimum RAM requirement of approximately 6-7 KB for a basic virtual machine

For the TypedArray Concat and TypedArray Find Within proposals.. the advancement to Stage 1 was contingent on me creating and transfering the github repos... that's been done:

1. Concat -> https://github.com/tc39/proposal-typedarray-concat
2. Find Within -> https://github.com/tc39/proposal-typedarray-findwithin

In the coming week I'll be adding the proposed spec text and assuming things are looking good, I do plan to go for Stage 2 (at least) by the next plenary