apologies. reading the github issue more closely, i'm not an expert on this matter.
-kai > On Dec 8, 2017, at 3:23 AM, Alex Vincent <ajvinc...@gmail.com> wrote: > > TLDR: -1 is much more useful in mathematics than in expressing an opinion. > > Mr. Zhu, > > In this case I am the implementer, and I generally know what I'm doing after > well over fifteen years of working with the language, including the membrane > library we're talking about, and including writing an 1100+ page book on the > language. (The latter taught me a lot, by the way. You should try it > sometime. It's a very humbling experience, both at the time for what you > thought you knew that's actually quite wrong, and much later in life, when > you realize what you still got wrong. I only hope Martin Honnen is still > around for me to reiterate my thanks to...) > > I shouldn't be worried about the garbage collector, and I'm not. > > But I do know how my membrane can (a) create and (b) hold onto references. > This wasn't about the garbage collector at all. This was about avoiding > creating the proxy and thus, the reference, in the first place. I am dealing > with the concept of "when is wrapping something in the membrane > counter-productive in some way". > > I said "essentially a memory leak", not meaning to be taken entirely > literally. It is a memory leak in the sense that unless somebody visits that > proxy again -- which no one will ever know if it's necessary or not -- the > reference to the proxy will remain alive. For that proxy to exist because of > a simple filter function is possibly less than ideal, to put it politely. > Especially when said filter function can be called many times for many > different objects. > > So yes, maybe it's premature optimization, and I'm always willing to admit > I'm wrong... when it's clear that I am. In my case, I'm not looking at > micromanagement of the gc, but to avoid certain work in the first place. > > Now, parsing a function's source code to find out if that function will, say, > set a global variable that it shouldn't, is probably pretty expensive as > well... except that the JavaScript engine has already done that parsing and > might have retained some useful metadata that the specification doesn't > expose. Which is why I'm not particularly interested in adding esprima and a > bunch of code I don't understand for a small bit of metadata. It's why I > came to this mailing list today, to ask the experts, "Hey, is this a good > idea to look into? I actually have a use-case, and it's not something that > can be easily done in raw JS." That's my understanding of the general > requirements for adding new API. > > I already explored at least two other ideas that turned into dead ends, and > it's quite possible (probable, given the feedback) that this one will be a > dead end too. I'm fine with that. > > So sure, asking end users to micromanage or optimize their code is > irresponsible. But I'm writing a library for developers to use, and if I can > provide advice on the best way to use that library, I think it's worth the > time to think about how that library works, and how to be nice to the > machines that it will run on. So I'd better think a lot about optimizing my > code, and about helping my users get the best reactions from it. > > On Thu, Dec 7, 2017 at 11:26 AM, kai zhu <kaizhu...@gmail.com > <mailto:kaizhu...@gmail.com>> wrote: >> 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 >> <mailto: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 <mailto:es-discuss@mozilla.org> >> https://mail.mozilla.org/listinfo/es-discuss >> <https://mail.mozilla.org/listinfo/es-discuss> > > > > > -- > "The first step in confirming there is a bug in someone else's work is > confirming there are no bugs in your own." > -- Alexander J. Vincent, June 30, 2001
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
