
Test if a function is pure, revisited - david90
https://glebbahmutov.com/blog/test-if-a-function-is-pure-revisited/
======
theseoafs
> 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
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
> `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
>This is language-specific for Javascript.

I said that in the context of the article obviously, which is about JS.

------
devishard
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.

------
dustingetz
lexical closures over const values are pure

------
emersonrsantos
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.

------
catnaroek
Observational purity of JavaScript functions is undecidable, obviously. Do
these guys not know basic CS?

~~~
acbabis
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
Then what exactly is the point to testing? Prove it for once and for all!

~~~
acbabis
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
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.

