Only extremely small subset of functions can be proven to be pure. And I suppose that these functions are already optimized by engines.
eg. notPure = (a,b) => a + b; // implicit conversion with side effects can happen notPure = (a) => a && a.b; // getter can be called notPure = (foo, bar) => Reflect.has(foo, bar); // proxy trap can be called. Someone could overwrite Reflect.has etc. It would be better idea to have builtin decorator *@pure* that allow engine to remove or reorganize function calls (and valid implementation can treat it as no-op). On Thu, Dec 7, 2017 at 5:22 PM, Alex Vincent <[email protected]> wrote: > TLDR: I'm asking for the group to consider adding a Function.isPure(func) > or isPureWithinScope() to the ECMAScript specification, to help code detect > pure functions. > > This morning, I had a thought experiment about membranes, and in > particular, callback functions passed into them. If the callback function > is called repeatedly for objects that will not be needed again, that means > one extra proxy for each object, which the membrane must remember. That's > effectively a memory leak. > > 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. > > But how can I tell from JavaScript, easily, whether a function is pure or > not? > > For reference, a quick search on es-discuss found [2], which is probably > worth re-reading. > > Determining whether a function is pure or not (or "only uses these > objects") is probably best left up to JavaScript parsers. Although it > could be done using esprima, I suppose, that's a lot to ask of a membrane. > > So the first question I have is, would this group actively consider adding > a built-in Function.isPure(func) method to the ECMAScript language? (Or > Function.prototype.isPure(), but I prefer the former.) > > Further, in the case where a function isn't pure but its side effects are > confined to local variables that won't live longer than the callback, that > might also be safe for not wrapping in the membrane. I'm thinking of a DOM > NodeFilter object where the acceptNode method modifies the filter, but the > filter is defined via a let statement in a small scope statement-block. > Since I don't know what to call this kind of function, I'll temporarily > call it "pure within a scope" until someone corrects me. What I mean by > "pure within a scope" is that the function's only side effects involve > objects within that set. > > The second question then is, would this group actively consider a built-in > function which takes a target function to test as its first argument and an > array of objects that are considered safe for that target function to work > with, and returns true if the target function has no side effects besides > directly impacting the objects in the array? (No, I don't know what to > call the built-in function. Maybe Function.isPureWithinScope(func, > safeObjectsArray).) > > Alex Vincent > Hayward, CA, U.S.A. > > [1] https://github.com/ajvincent/es7-membrane/issues/141 > [2] https://esdiscuss.org/topic/pure-functions-in-ecmascript > > -- > "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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
