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

Peter Jaszkowiak p.jaszkow at gmail.com
Thu Dec 7 18:18:31 UTC 2017


Seems like you're asking for a check for if the function is a closure. If
it maintains references to variables outside the scope of the function.

So would an `isClosure` function work for at least a little of what you
want?

On Dec 7, 2017 11:11, "Alex Vincent" <ajvincent at 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?
>
> Call this check "is relatively pure", or "is locally pure", if you
> desire.  If the inputs themselves manipulate globals, "absolutely pure" can
> never be guaranteed, as was just demonstrated...
>
> On Thu, Dec 7, 2017 at 9:35 AM, Michael Haufe <tno at thenewobjective.com>
> wrote:
>
>> Relevant discussions:
>>
>> <https://groups.google.com/d/msg/mozilla.dev.tech.js-engine/
>> aSKg4LujHuM/2Y9ORBwCIQAJ>
>>
>> and:
>>
>> <https://mail.mozilla.org/pipermail/es-discuss/2012-November
>> /thread.html#26657>
>>
>>
>> On Thu, Dec 7, 2017 at 11:15 AM, Michał Wadas <michalwadas at gmail.com>
>> wrote:
>>
>>> 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).
>>>
>>
>
>
> --
> "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 mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171207/ac21287c/attachment-0001.html>


More information about the es-discuss mailing list