Mark S. Miller

> Caja's initial attempt at SAFE_INTEGER used 2**53 rather than 2**53 - 1. This resulted in an exploitable security hole. Arguably decimal will be less hazard prone. But not less...

Great analysis! Fair enumeration of pros and cons. The key issue for me is that decimal will be only one of many upcoming numeric or numeric-like types, by which I...

Regarding money, [Agoric](https:agoric.com) would never use decimal for it anyway, even if it were in the language. To us, the only good representation for money is BigInt, in terms of...

> Are you saying, we should take all of the tradeoffs above (=== not useful, Maps/Sets counter-intuitive, and always truthy) for decimals? yes > Beyond consistency properties of the language,...

I'm fine with continuing to try to get general extensible value types working. If we do, do you agree that the above bulleted examples of things that would overload operators...

For reasons explained at https://github.com/tc39/proposal-weakrefs/issues/22#issuecomment-491097466 we no longer need a System object, or a standardized whitelist of globals.

Still need separate globals. As you pointed out, with `System`, we'd only need one global, rather than two for error stacks and another two for weakrefs. I would still prefer...

> There needs to be a working polyfill, likely adapted from https://rawgit.com/tvcutsem/es-lab/master/src/ses/contract.html (stage 2 concern) Shim/polyfill started at https://github.com/erights/error-stack-shim

Ironically, v8 is the one engine on which a shim does not need to parse/scrape the text representation. We use the v8 Error APIs directly. How applicable is your parser...

> However, it seems that aforementioned resolveWithPresence function creates the presence object instead of taking one as its second argument. Yes. We used to take a presence as an argument....