> This led down a long, rambling path [1] 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.
-1 users generally should not be encouraged to micro-manage/optimize the gc in javascript (javascript is not c). that is the responsibility of engine-implementers. making users think they can outsmart the gc (which they don't) will only encourage them to waste time writing “high-performance” code that is bike-shedding at best and tech-debt at worst (and my suspicion is membrane/proxy will suffer either of those fates with this feature). > On Dec 8, 2017, at 2:22 AM, Mike Samuel <mikesam...@gmail.com> wrote: > > > > On Thu, Dec 7, 2017 at 1:11 PM, Alex Vincent <ajvinc...@gmail.com > <mailto:ajvinc...@gmail.com>> wrote: > > OK, OK, clearly, pure functions are a fantasy in JavaScript. Once again, a > > 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@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
