5 ms·

Test if a function is pure, revisited

• catnaroek 11y ago
  Observational purity of JavaScript functions is undecidable, obviously. Do these guys not know basic CS?
  • acbabis 11y ago
    The writer says as much toward the end of their article: > trying to prove that the output changes is the same as trying to prove that the program finishes writing. Thus it is theoretically undecidable.
    • catnaroek 11y ago
      Then what exactly is the point to testing? Prove it for once and for all!
      • acbabis 11y ago
        That's fair. I think it makes more sense to write a function you know is functional and then test for expected output. I'm not sure under what circumstances you wouldn't be sure if your code was functional.
        • catnaroek 11y ago
          I can think of situations where a compiler couldn't figure out on its own that your code is purely functional. For example, when you do dynamic programming, you internally use mutation (memoizing previous results) to speed up the evaluation of a recursive pure function. Outside parties shouldn't be able to see anything impure going on. Lazy evaluation is a special case of this idea. But I can't think of any situation where the programmer shouldn't know beforehand whether the procedure he or she's implementing evaluates a pure function.
      • AnimalMuppet 11y ago
        I can agree that "prove it" is preferable, in theory. But the amount of code for which we can actually prove any property we care about is much smaller than the amount of code we wish to write. An automated approach, even if not perfect, is often better than "no proof at all", and also better than "no code at all" (or "you can't have that code until I get around to proving it", which amounts to the same thing).
  • sotojuan 11y ago
    The author has a PhD.
• dustingetz 11y ago
  lexical closures over const values are pure
• emersonrsantos 11y ago
  My favorite part of the article: > Relaxing the rules and allowing accessing other pure functions or constant values is fine, as long as the function is still consistent.
• theseoafs 11y ago
  > I have been adding more examples to the list asking if each example is pure or not. Seems even humans sometimes have trouble drawing a line. For example, everyone agrees the following example is pure > function sum(a, b) { return a + b } > and this example is NOT > const k = 2 > function addK(a) { return a + k } This is wrong. Assuming the variable `k` is properly constant (never changes), `addK` is still a pure function. The author seems to have gotten confused because they are working from an incorrect definition of what "purity" means.
  • Arnavion 11y ago
    It's not wrong in general. `const` is a property of the binding, not the value. If it were an object instead of the literal `2` then the author's point would be valid.
    • theseoafs 11y ago
      > `const` is a property of the binding, not the value. This is language-specific for Javascript. > It's not wrong in general. It's not wrong in general, but it's also not right in general. The pattern is completely orthogonal to purity. Whether a closure is pure depends on a lot of factors, like the types of things in the closure and the functions it calls.
      • Arnavion 11y ago
        >This is language-specific for Javascript. I said that in the context of the article obviously, which is about JS.
• devishard 11y ago
  The author seems to not quite have figured out what he wants to say here: clearly he knows that JS purity is undecidable, Might I suggest looking into a subsets of JavaScript where purity is decidable? It seems like the author is intuiting that purity is decidable for some nontrivial subset of JS (this is my intuition as well). I think that we can determine cost variables assigned to a primitive value to be pure. From there we can build up that const functions which only contain pure expressions are pure. Note that this does not include fields on objects of any kind: a.b and a[b] are not necessarily pure even if both a and b are. In this way, I think we can determine that a subset of JS is pure. We can't, however, prove that any subset is not pure. Nevertheless, even proving a small subset to be pure might have implications for optimization.