On Wed, Dec 4, 2013 at 3:22 PM, Mark Miller <[email protected]> wrote: > On Wed, Dec 4, 2013 at 12:12 PM, Sam Tobin-Hochstadt <[email protected]> > wrote: >> >> On Wed, Dec 4, 2013 at 3:04 PM, Mark Miller <[email protected]> wrote: >> > Hi Sam, I read and followed your message, but I'm now confused about the >> > topic. Are we discussing hypothetical variants of JS in which we are >> > happy >> > to trust user code to uphold system invariants? Or are we discussing >> > what >> > can actually be done in current and future JS? If the former, I agree, >> > but >> > why is this a more interesting question than what we would do if we had >> > even >> > fewer legacy constraints? >> >> My impression is we're talking about whether it's sensible to propose >> a change that extends the behavior of proxies with regard to equality >> (whether that's `===` or some other form of equality). I don't think >> I was assuming that we trust user code to uphold system constraints. >> Instead, I was arguing that the restriction to "checkably pure" code >> is insufficient when you actually don't trust the other code, and >> excessive when you do. > > > That's interesting. Could you expand on the "insufficient" part of the > argument? I hadn't gotten that. Thanks.
The most obvious way that it's insufficient is that resource consumption is an important effect. For example, we added `chaperone?` in Racket -- the equivalent would be `isProxy` in JS -- in order to avoid calling any potentially long-running code when a particular critical lock was held in a part of the GUI system implementation. The second way is that errors and other forms of non-termination are effects, which can be visible to code outside of the proxy. Whether that be a TypeError, or an infinite loop, checkable purity as described in the Joe-E paper doesn't rule this out. A more fundamental problem, however, is that checkable purity in the sense of the Joe-E paper is not a reasonable strategy for proxy handlers. In particular, proxy handlers have access to (a) the object being proxied and (b) the arguments to the operation performed on the proxy. The checkable purity strategy would require that both of these be immutable, but that would restrict these checkably-pure proxy handlers to transitively-immutable first-order data, making them basically useless. Sam _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
