In a wide sense the type is also “context”, a==b has a boolean type, which provides context in this sense.
I am actually wondering, I am not sure it’s possible, I am not an expert in compilers but I can’t imagine a normal situation where a compiler could not decide out of context what to do or, at the very least, throw a ambiguity error, could you provide an example of such impossibility in Julia?
But you are not talking about deciding this based on types, as far as I can tell. Types are a kind of context, but context is not a kind of type.
The example we are discussing in this thread. I’m not talking about what is possible for a compiler, I a technical sense, but from a philosophical standpoint. I’m saying there is no way to tell if the user intended something other than what was written here. Throwing an ambiguity error, or trying to ‘interpret’ and change the meaning of
if (x = a)
would be bad, because the user could intend this exact thing, and it makes sense to do, even if it’s less common.
I think this case is already handled by context in Julia when not a bool:
julia> if (x=a)
print(1)
end
ERROR: TypeError: non-boolean (Int64) used in boolean context
and if x and a are both bool then the if could set the context for an equality test, which is not what Julia does, but it could.
Well, this context is kind of Boolean.
ERROR: TypeError: non-boolean (Int64) used in boolean context
But there are also other problematic cases like:
a=b=c vs a=(b=c)
The first case assigns c to b and a and so does the second case even if the intent is to assign a bool to a. So if not impossible in other languages I don’t think it’s gonna happen in Julia… However, I still don’t see insurmountable problems for a compiler to set rules for context, at least in those two basic examples.
What would the context of
if (a=b) < 5
then be? VBA does what you are proposing (it uses = for assignment and for equality checking), but it’s syntax is very poor and constrained. You can special-case all the places where one choice is made over the other, but that just makes things inconsistent and takes away some of the expressionness of the language.
Also, what about
a = b = (c = 3)
If we go down the path of actually just using = then we need to agree on some convention to break ambiguities. For instance, let’s agree that in a Boolean context = is always an equality test, and in your example
(a=b) would be an equality test, and if we meant it to be an assignment then we do:
a=b
if a<5
For your second example:
Just like we use parenthesis to adjust conventions in expression like a*(b+c) we can do likewise here and establish something like “in a non Boolean context = is an assignment unless between parenthesis”. Then
a = b = c = 3 assigns 3 to a,b and c
a = b = (c=3) assigns the bool (c=3) to a and b
Let me say that I am not really pushing for a change in Julia, I am just curious about if using == is more of a historical thing we do because pioneers did it and we go along with it, or if there is a deeper technical reason for it.
At what point does the cognitive load of interpreting what = might mean in whatever context become greater than simply remembering and applying different operators, however they may look? It is arguably easier (and more efficient) for humans to parse different symbols.
Then, this discussion becomes one of which symbols to use and that is arguably a subjective matter and thus comes down to personal preference or your willingness to learn and apply new syntax.
Julia is already great insofar that it allows you to define your own operators. It was proposed by OP and demonstrated later that you can personally define whatever unicode alternative to == that you wish. It is thus strictly not necessary to fix this operator but let anybody choose according to their own personal preference. (Differing styles really become only a problem in projects with lots of contributers. But they have to discuss style-guides anyway.)
Albeit, I’m not even sure how exchanging == for ⩵ is going to help OP in any way. If they can’t remember to use ==, why would they magically remember ⩵? They even look exactly the same in this specific case… genuinely curious to hear the thought process behind this.
And to be clear, I have stake in this discussion. I would love to use ** instead of ^ (albeit for completely esthetic reasons) but in this very specific case Julia actually actively disallows me to define **. Do I ask, let alone demand anything? Even for 2.0? No, I understand why this was done and Julia has the syntax it has, like any other language. (The “hardwire issue” is of course a different one. This is not meant as a direct comparison.)
Irrespective of how good or bad == is (I’m pro), please never write if (flag = booleanfunction()). Even if it’s intentional, you are just making the code harder to interpret. For what, a single line less of code? Why don’t we just go back to the C hacks like while(*a++ = *b++)? Contrary to popular belief this is not good programming, because it’s impossible to read.
Wooow, what? That’s interesting. Would you mind explaining? I always found this to be one of the most bizarre things in python.
The ^ is almost universally used as the superscript/exponentiation symbol, to the point where I’m pretty sure most people who know nothing of maths or programming will recognize it (just think of ‘m^2’ or ‘E=mc^2’).
So I always found the decision in python utterly confounding. But, you actually prefer this? What’s the story?
(To ramble on: the ** is particularly annoying in math-heavy code with lots of exponentiation, since it’s more verbose, and less visually distinct from multiplication).
I just had a thought: were you talking about string concatenation?
You could take the Python route of disallowing
if (a = b)
and instead requiring the more visually distinctive walrus operator, which is also much harder to mistype:
if (a := b)
This wouldn’t really affect many people’s programs, I don’t think, but it would definitely avoid bugs.
Mathematicians have been using = and switching its context with symbols like ∀ for hundreds of years, none of them seemed to ever had a cognitive need for ==
With all due respects, I find this comment unwelcoming and discourages discourse
If they can’t remember to use ==, why would they magically remember ⩵?
It’s not that I don’t know the proper operator or syntax – it’s that a slip is made when the right pinky finger goes to type == and only types =.
A Unicode alias for == would be entered as, say, \ie – so pinky never hits = key and no slip is possible. Currently already type \ne for not equals.
** originated with FORTRAN I believe. Many languages use it.
Neither ** nor ^ look great in long formulas.
I don’t understand that at all. I could empathize with the version where your brain goes “equals” so your fingers go =, which a unicode alias would do nothing against. I really can’t imagine knowing to write two signs and accidentally just writing the one. Do you often misspell other double characters?
Albeit, I’m not even sure how exchanging
==for⩵is going to help OP in any way. If they can’t remember to use==, why would they magically remember⩵? They even look exactly the same in this specific case… genuinely curious to hear the thought process behind this.
I’m going to come clean here: I have a Unicode addiction. If I have the option to use either Unicode or ASCII, I will always use Unicode, and I will never forget. I don’t understand why my brain works this way, but it does, and we’ll probably need a crack team of brain surgeons to figure both me and the OP out.
IMO, the technical reason is: in Julia, ANY expression is valid after an if. If = was to be treated differently, then what about other operators, keywords and syntaxes (e.g. let, begin, try ... catch ... end)?
Of course you could argue that only a few expressions should be used in test context, but a whole new set of rules would have to be made.
A more appropriate comparison, IMO, would be formal languages. Usually Math articles don’t use formal language to prove theorems, but programming languages are formal languages, even if they are made more complex in order to be more human-readable.