Here is some code of mine without the TypeError: __call__() missing 1 required positional argument: 'self'. How do you create this error?
>>> class X(Exception):
def __call__(self):
raise self
>>> x = X()
>>> x()
Traceback (most recent call last):
File "<pyshell#5>", line 1, in <module>
x()
File "<pyshell#3>", line 3, in __call__
raise self
X
>>> class Other(X):
pass
>>> o = Other()
>>> o()
Traceback (most recent call last):
File "<pyshell#12>", line 1, in <module>
o()
File "<pyshell#3>", line 3, in __call__
raise self
Other
You've already created at least one inconsistency, and a particularly damning one at that - treating functions differently from other values. A function declaration is conceptually the same as binding a variable to an anonymous function, but you're asserting that "regular" variables don't get hoisted while function declarations do. So...
f()
function f() { /* ... */ }
Works, but...
f()
var f = function() { /* ... */ } // Pretend this is anonymous function syntax
Doesn't. (And if you don't allow passing functions around like any other value, your language is horribly crippled.) Next, what happens if a function is redefined?
f()
function f() { /* definition 1 */ }
...
function f() { /* definition 2 */ }
If you treat this as an error, you're once again rejecting functions as values. There's no reason you shouldn't be able to do:
var f = function() { /* def 1 */ }
f = function() { /* def 2 */ }
So let's assume you'll allow the function to be redefined. How do you deal with lexical scoping?
function f() { /* definition 1 */ }
function bar() {
f()
function f() { /* definition 2 */ }
If you hoist definition 2 to the top of bar's scope, you end up with this:
function f() { /* definition 1 */ }
function bar() {
function f() { /* definition 2 */ }
f()
Which means you can never call the outer definition from a nested scope unless you give the inner function a different name. Moreover, in any other language, the meaning of the above program is independent of the choice of name for definition 2. The hoisting rule changes the meaning depending on whether there's a name collision or not. On the other hand if you don't hoist definition 2 to the top of bar, you've broken your own rule.
Best Answer
To answer your title question "Does any programming language use variables as they're in maths?": C, C#, Java, C++, and any other C style language use variables in the way they are used in math.
You just need to use == instead of =.
If I take your original
Then I can translate that into C# directly without any changes other than for the syntax.
Math.Sqrt(Math.Pow(x,2)) == Math.Abs(x)This will evaluate to true for any value of x as long as x squared is less than the max for the data type you are using. (Java will be grossly similar, but I believe the Math namespace is a bit different)
This next bit will fail to compile in C# because the compiler is smart enough to know I can't assign the return of one operation to another operation.
Math.Sqrt(Math.Pow(x,2)) = Math.Abs(x)Immutability has nothing to do with this. You still need to assign the value in an immutable language and it's entirely possible that a given language may chose to do this by using = as the operator.
Further proving the point, this loop will run until you exhaust legal values of x and get an overflow exception:
This is why mathematicians hate the use of = for assignment. It confuses them. I think this has led you to confuse yourself. Take your example
When I turn this into algebra, I get this:
abs(2x) = root(x^2)
Which of course is not true for values other than 0. Immutability only saves you from the error of changing the value of x when you add extra steps between evaluating the Left Hand Side and Right Hand Side of the original equation. It's doesn't actually change how you evaluate the expression.