Identifying pure (or "pure within a scope") JavaScript functions?

Michał Wadas michalwadas at
Thu Dec 7 17:15:00 UTC 2017

Only extremely small subset of functions can be proven to be pure. And I
suppose that these functions are already optimized by engines.

notPure = (a,b) => a + b; // implicit conversion with side effects can
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


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 <ajvincent at> 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]
> [2]
> --
> "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 at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list