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

kdex kdex at kdex.de
Thu Dec 7 16:33:35 UTC 2017


So… is the following function pure?

let env = 1;
function tryMe() {
	if (false) {
		env = 2;
	}
}

On Thursday, December 7, 2017 5:22:37 PM CET Alex Vincent 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171207/a062d297/attachment.sig>


More information about the es-discuss mailing list