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 <[email protected]> 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 <[email protected]> > 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
