Details of mathjs function closures and bound and free variables

[gwhitney]

This posting has two parts. In the first, I detail some aspects of how mathjs expression language function closures work, to surface them and make sure they are intentional design decisions.

Second, I raise what was to me a surprise in the behavior of bound variables, which has some interaction with the first point.

1: In slogan form, function definitions close over variables bound in a containing syntactic environment, but not unbound variables.
To see this behavior, evaluate g(y) = f(x) = y*x +k (with a so-called "scope" that has a binding for k, say set to 3). Then evaluate F=g(10) and H=g(-2). You can then check that F(5) returns 53, and H(5) returns -7 = -2*5 + 3. Now set k to 7 in the scope provided when the expression defining g was evaluated. Then check that F(5) returns 57 and H(5) returns -3. You can also check that any value that y might have in the scope provided when g was defined has no effect on the behavior of F or H. To summarize, the execution of each function f returned by g uses the current ("dynamic") value of k from the scope in which g was defined, but uses the ("lexical") y value in effect within g when it is called and that instance of f is defined.

These scoping rules may be exactly as designed. The mathjs documentation explicitly states that function definitions do not close over the values of free variables, but it is silent on the behavior with respect to variables bound in enclosing syntactic environments. And certainly the lexical scoping for y is useful, as it allows one to write function factories within mathjs (e.g., the "addn" function that given n, returns a function that adds n to its argument). So perhaps the documentation of function definitions should be elaborated to note this behavior.

2: Bound variables are not writable. To see this, try f(x) = (x=x+1) > 2 ? x : x.a and then evaluate f(2). It returns 2, even though the x=x+1 must have been evaluated before the x in the true part (as proven because the illegal x.a in the false part does not error, or because evaluating k = 2; (k=k+1) > 2 ? k : k.a produces 3). If x were writable, f(2) should have returned 3.

This limitation on bound variables prevents one from using a closure over outer bound variables to generate functions with "private variables," e.g., you can't write a counter generator as countergen(y) = (y=0) == 0 ? counter() = (y=y+1) : undefined

Is it intentional that bound variables cannot be assigned to? (If they happen to be objects, they can be mutated, so the following counter generator works: countergen(y) = (y.cnt = 0) == 0 ? counter() = (y.cnt = y.cnt + 1) : undefined as long as you call countergen with an object, e.g. ctr = countergen({}) lets you call ctr() repeatedly and get 1, 2, 3, ...)

If not, then that's a bug that should be filed as an issue, to allow bound variables to be reassigned.

If it is the intentional designed behavior, then it seems to me that at least, the read-only nature of bound variables should be documented, but more, it seems to me that attempts to assign to a bound variable should throw an error, to avoid code that appears to be calculating with bound variables but is not. If there's agreement on that, then I will file an issue to implement such an error.

Looking forward to thoughts/responses.