My Brain Is Hard-Wired Against ==; Help Me, Julia

New to Julia
,
1

Equality in Julia is tested using ==

x = 5
if x == 5
	println("x is five!")
end

However, a mistake I make all the time, even several times a day, over a period of several years, is to use = instead of == :

x = 5
if x = 5  # error
	println("x is five!")
end

Recent Example 1:
I was writing some Julia code in the past week, where I needed to test a variable against several possible values – six in all:

if member=="SB" ...etc
if member=="SL" ...etc
if member=="SU" ...etc
if member="SN" ... etc
if member="ST" ... etc
if member="AUTO" ... etc

Yes, in writing six lines of code, I made the mistake 3 times. Then I cut and pasted it into about 4 other places.

I know what you’re thinking: what about that syntax highlighting in VSCode?
My Brain: “Oh, what pretty colors”

Recent Example 2:
While I was thinking of this post, I updated some C++ code. I added an if-then using “=” instead of “==” – and this was underneath two existing if-then statements that had it correct.

After 20+ years of math education, “=” for equality is not only permanently hard-wired into my brain, the wires are constructed of tungsten, with a cover of pure neutroium, and further protected by a think layer of concrete.

I Don’t Think I’m Alone In This
I know that SAS JMP, if you execute a JSL script, if the parser finds a “=” used in an if-then statement, pops up a dialog box saying, “Is this really what you want?”

How Julia Can Help

One of the great features of Julia is unicode operators. We can use ≠ for not equals, ≤ for less than or equals, and ≥ for greater than or equals. We even have ≡ for equivalence. It really cleans up if-then statements and makes them clearer.

What I would ask for is a Unicode alias for ==

What Symbol Could It Be?

I present to you three possibilities:
U+0225F ≟ (question equals) \questeq
U+0229C ⊜ (circled equals) \circledequal
U+02A75 ⩵ (two consecutive equal signs) \Equal or \Equ

Shortcut to type it:

I don’t care which symbol is chosen (:cactus: anyone? anyone?), but I would like the shortcut to enter it to be easy to type. That generally means: short, lowercase, and easy keys to reach for touch typists.

Unfortunately, ≡ is already using \eq.

⩵ has a shortcut, \Equ

I would prefer one that is all lower case (say, re-asigning \ieq ). But I could live with \Equ. It’s not too bad to type.

I would use it every time. As long as my right pinky stays of the = key, I won’t make the mistake.

Pathetic Begging

\huge\textbf{In the name of all that is good}\\ \huge\textbf{and holy, I beseech you:}\\ \huge\textbf{create a Unicode alias for ==}

Thank you for your consideration.

4 Likes
2

You can do it yourself

julia> a ≟ b = a == b
≟ (generic function with 1 method)
julia> 4 ≟ 4
true
12 Likes
3

Yes, but it’s not quite the same. You end up being the one creepy dude in the world who re-assigns == . Library maintainers send you puzzled questions.

2 Likes
4

You don’t want to change the meaning of == right? You just want another character that means the same thing as == to be in Base?

4 Likes
5

Not alone in a mathematical strict sense, but I would say, it’s pretty near to alone. :wink:

24 Likes
6

Nay, that’s fine, others can just look up the function in your code, the tooling is there, like for any other function.

If you want an alias, just do it as @jzr suggested, but it is unlikely that you can make others change the way they code, or that the language should support you in this attempt.

(I am also recategorizing this into Usage — First steps.)

6 Likes
7

Yes, exactly.

8

I don’t really see this as making others change the way they code. They are still free to use ==.

It’s more like it completes the set of ≠ ≤ ≥ ; people are still free to use != <= >=

or that the language should support you in this attempt.

It seems like a trivial implementation. Again, it completes the set of != <= >=. The new set would be, say, ≠ ≤ ⩵ ≥

It doesn’t break anything and it is an aid to users of differing experience levels.

4 Likes
9

I don’t know what you experience level is, but of the people I interact with, this is a common error.

To repeat: SAS JMP, when executing a JSL script, has a special check for the use of “=” in If-then statements and pops up a warning box if it is found. Why would they do this? Because their users make that mistake frequently.

Why does VSCode use syntax highlighting if it is found? Because it is a common error.

You might ask around a bit.

1 Like
10

Technically it would break code already using these symbols as a function name or something.

Also, while I appreciate (but do not really understand) that you dislike ==, this does not seem like a widespread problem. Finally, the aliases you suggest are not conventionally used for equality, so it is unclear how this would help anyone.

The great thing about Julia is that you can tailor it to your own needs and coding style, easily, with zero or near-zero performance overhead (in this case, zero), in your own code. In most cases, you don’t need to change the language.

5 Likes
11

I agree it’s a bit of a mess that we have =, which is entirely different from ==, which is subtly different from ===. That’s an open invitation for errors.

Unfortunately, it’s something Julia has inherited from other languages. Most languages (that I know of) uses == for equality. Is that a good enough argument that other languages do it? I’m indecisive. On one hand, having your language “feel” like other languages makes it much easier to learn for people who are already familiar with the other languages. On the other hand, that line of reasoning means we should never fix any design problems with old languages (imagine if we all wrote in ALGOL60 style!)

I’m convinced that it would be a very bad idea to introduce new, fundamental operators now though, three years after Julia has gone stable. For better or worse, it’s a design decision that is carved in stone now.

1 Like
12

There are a lot of common errors. E.g. forgetting ; at the end of a line, forgetting a closing " at the end of a string, using ' instead of " for strings, just to name a few which come to mind for this and other languages.

The equality operator “==” instead of mathematical “=” is very common in the zoo of languages and is of course a result of “=” being already the assignment operator.

What I want to say with my previous comment, is that I don’t think that implying that this error is a common thing by stating “I am not alone” doesn’t make a good argument.

Your original post doesn’t seem to be too serious, as there are some funny exaggerations which I appreciate, so don’t take me too serious, when I seemingly oppose your request which I don’t: If anyone wants to give Julia a Unicode “==” operator I am happy and won’t use it.

This seems to something which can be let as it is.

7 Likes
13

Duplicate code is considered a code smell. Hence, it indicates that there might a deeper problem with the organization of the code. Could the code be moved into a package and re-used from there?

5 Likes
14

All notation is arbitrary. Even the = sign was just invented at some point for equality, but now our eyes are used to it because of exposure starting in elementary school. There is nothing intrinsically good or bad about it, or = and ==, they are just conventions.

Symbols for operators are a top 3 bikeshedding topic, but ultimately matter little for a language so they are not worth spending too much time on.

Also, not using up a lot of the Unicode operator selection with various defaults was a very sane decision for Julia, since that allows users to make use of them.

8 Likes
15

If you choose to do this I suggest:

“circled equals” looks odd to me, with my eyesight looks like a face, and the third option didn’t seem available in the font, such option would be bad. E.g. \ieq and \Eq are not taken, and something like that could be an alias for \questeq. I just can’t see it helping your typing speed… There’s precedent for two, e.g. \sqrt and \surd, meaning the same.

If you make a PR, here’s the file:

2 Likes
16

It would be a horrible solution, but I’m just thinking, could you still make a Julia macro that changes = to == just in those places? I think it can be done, and you could apply it to all your functions…, which would be annoying, so the next question, can you apply a macro to a whole file instead? I don’t think that’s possible. And also, I’ve sometimes wanted to know if you can see the generated code after macro substitution, is that possible, i.e. in human-readable form, with same Julia syntax?

Whatever you do, I would run your code through some text substitution macro (e.g. in your editor) that changes ≟ back to ==. Before you commit or show others your code.

17

I don’t see how an alias for == would help with your original problem of mistakenly using = when you mean ==. What’s the connection?

8 Likes
18

I understand you very well and I am glad to see that I am not alone…

It reminds me of this post…

Personally, as I often work with SQL, XSL (and XPath), I regularly make this mistake too by putting = instead of == for equality, and as the ≠ symbol is shorter and cleaner (I never use !=), I tend to do my tests reversed with ≠ instead of direct ==…

1 Like
19

I disagree, I think it’s generally a bad idea to introduce non-standard syntax without a strong reason. “Others can just look up…” may be right but missing the larger picture, which is that even small non-standard things add up. This can make codebases significantly less accessible to new readers/contributors. Even one idiosyncrasy is an unnecessary obstacle that can be annoying to people who jump through many codebases in a single day.

Sure, tooling can help to read non-standard syntax, but it’s much better to use tooling to make non-standard syntax unnecessary.

In the present case, I think the right solution for @blackeneth is to make a VS Code plugin or whatever that analyzes the code and reports any use of assignments as expressions (e.g. underlines code like if a = b ... that use the return value of a = b).

1 Like
20

I fully agree with you, but given that @blackeneth’s

brain is hard-wired against ==

I am not sure that there is anything else that can be done here, short of consulting a brain specialist.

(I was under the impression that the human brain retains considerable neuroplasticity during most of one’s lifespan, definitely enough to deal with stuff like ==, but it would be churlish of me to dispute people’s claims about their own brain, which they surely know best.)

12 Likes