The main issue with the evaluation rules is that Mathematica doesn't distinguish between creating a symbolic expression and evaluating code. That is if I type
f[x]
and the function `f` is not defined, Mathematica will not give me an error but instead just assume that I meant to create a symbolic expression. If you know some Lisp, just imagine that everything came with an implicit `quote` which would automatically get invoked whenever a unbound variable or function would we encountered.
That issue alone has caused me so many errors simply from mistyping some function or variable name. For simple expressions, such bugs are pretty obvious to spot but if the same occurs deep inside a chain of function calls, this often lead to completely wrong results because the bug got masked by some other manipulations I did on the result of the function call.
Of course, there are tons of hacks and ad-hoc workarounds in Mathematica to get around this (imho fundamentally broken) behaviour to the tune of "just stick another `Evaluate` here" or "just change the function definition from `g[x_]` to `g[x_?NumericQ]` to call the function only when the argument is numeric and otherwise leave it unevaluated".
The situation with the scoping rules is not much better. Consider for instance the following code:
y = 1;
expression = Module[{y},1+y]; (* Module creates a new scope in which y is unbound *)
Can you guess what happens if I print out `expression` now?
Print[expression]
1+y$4066
Yes, Mathematica has just renamed our variable. If now we wanted to set `y` in our expression to some concrete value, of course the obvious thing to try doesn't work, but just gives me some bullshit:
Print[ReplaceAll[expression, y->10]]
10+y$4066
These are all only some simple examples of why doing any kind of metaprogramming in Mathematica just sucks.
> and the function `f` is not defined, Mathematica will not give me an error but instead just assume that I meant to create a symbolic expression.
I've dreamed about creating a language like this, but had to give up because it makes diagnostics impossible in case o typos and things like that..
My best bet now is to have some quote syntax to make a symbol stand for an abstract symbol, like
1 + x -- this sums 1 with x, and errors if x is unbound
1 + 'x -- this is an abstract expression, doesn't care if x is bound or not
Like lisp, except with some first class support to things like derive(1 + 'x, 'x), and, well, every operator needs to respect quoted symbols.. even if + were a user-defined operator or function, 1 + 'x needs to return (the AST) 1 + 'x. I suppose this is the same as Mathematica, except that Mathematica doesn't need quoting
I don't really know what more you wanted from `Module[{y}, 1+y] /. y -> 10`. You've explicitly asked for a new symbol that is unrelated to the global one, and then replaced any occurrences of the global one with 10. Of course there are no occurrences of the global one.
I claim any semantics which resulted in `11` would be extremely confusing, because it would imply the following also resulting in `11`, which is obvious nonsense:
> I claim any semantics which resulted in `11` would be extremely confusing, because it would imply the following also resulting in `11`, which is obvious nonsense:
> y = 10;
> Module[{y}, 1+y]
Yes that is precisely the point: because of Mathematicas weird evaluation model, you cannot have ordinary lexical scope as in every other programming language, but the only sensible thing to do is to rename variables under the hood. It is then very easy to leak those renamed variables accidentally in the global scope where you cannot do anything useful with them, because the symbols `y` in the global scope and in the subscope are different.
Another point that the example was meant to illustrate is that once you assign some value to a variable, you can no longer do symbolic manipulation with it (note that in the example, we have replaced 1 by 10 in the end).
That issue alone has caused me so many errors simply from mistyping some function or variable name. For simple expressions, such bugs are pretty obvious to spot but if the same occurs deep inside a chain of function calls, this often lead to completely wrong results because the bug got masked by some other manipulations I did on the result of the function call.
Of course, there are tons of hacks and ad-hoc workarounds in Mathematica to get around this (imho fundamentally broken) behaviour to the tune of "just stick another `Evaluate` here" or "just change the function definition from `g[x_]` to `g[x_?NumericQ]` to call the function only when the argument is numeric and otherwise leave it unevaluated".
The situation with the scoping rules is not much better. Consider for instance the following code:
Can you guess what happens if I print out `expression` now? Yes, Mathematica has just renamed our variable. If now we wanted to set `y` in our expression to some concrete value, of course the obvious thing to try doesn't work, but just gives me some bullshit: These are all only some simple examples of why doing any kind of metaprogramming in Mathematica just sucks.