kaizhu256 at gmail.com
Thu Dec 7 19:26:24 UTC 2017
> This led down a long, rambling path  where I then realized: if the callback function is a pure function, then for the purposes of that callback, the arguments probably do not need to be wrapped in proxies at all. The big catch is that the callback can't store any of the arguments in variables external to the callback (a classic side effect). If the function really is pure, though, I can avoid the memory leak.
> On Dec 8, 2017, at 2:22 AM, Mike Samuel <mikesamuel at gmail.com> wrote:
> On Thu, Dec 7, 2017 at 1:11 PM, Alex Vincent <ajvincent at gmail.com <mailto:ajvincent at gmail.com>> wrote:
> > great idea and a lengthy essay of a post falls to a real-world situation.
> > Nuts.
> > What if there's a middle ground? In the case I was originally talking
> > about, the developer calling on my membrane controls how the callback
> > function executes. I just want to ensure that, when the callback is passed
> > controlled and trusted arguments (including possibly "this"), the function
> > doesn't refer to anything outside those arguments and local variables
> > derived from them. Is that reasonable to ask for?
> Do you want the same kind of thing that Joe-E provides for Java?
> http://www.cs.berkeley.edu/~daw/papers/pure-ccs08.pdf <http://www.cs.berkeley.edu/~daw/papers/pure-ccs08.pdf>
> > Proving that particular methods within a code base are functionally
> > pure—deterministic and side-effect free—would aid verification of
> > security properties including function invertibility, reproducibility of
> > computation, and safety of untrusted code execution. Until now it
> > has not been possible to automatically prove a method is functionally
> > pure within a high-level imperative language in wide use, such as Java.
> Nothing that is well established really fits for JS, but there are some
> proposals and experimental features.
> The frozen realms proposal <https://github.com/tc39/proposal-frozen-realms> might also be of interest.
> > Though initially separate, realms can be brought into intimate
> > contact with each other via host-provided APIs.
> In a browser setting, WebAssembly <http://webassembly.org/docs/js/#webassemblyinstance-constructor> might be your best bet.
> WebAssembly.instantiate(module,importsObj) runs a sandboxed binary
> that has access to functions and values in an importsObject, and
> takes care to prevent following backwards edges in the object graph
> (__proto__, .constructor and the like).
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss