I don’t think it really helps those users. If they want to use Julia, they are better off just learning it as is. For one thing, running your private version of Julia with custom operators makes it much more difficult to ask for help.
In that regard, I think
:= was only included in Python a few months ago? It is not like it is a long held standard, so It doesn’t look like it missing from Julia is a difficulty for people that just learned that operator. It doesn’t seem right to follow Python syntax everytime they add something.
Let’s not make Julia suffer for the poor decisions made during the development of Python and Pascal.
Same, and for people, like me, who use a lot of Unicode characters, make
← (for example, same as
<-) a natural alias for this
:=. I also always feel strange when an equality test is longer than an inequality one in my code (
==), making me often choose to test inequalities to avoid mistakes (confusion with
It was very controversial during the proposal process and many Pythonistas still consider that change a mistake.
All this discussion of making Julia look like another language reminds me of the days when people would abuse the C preprocessor to make their C code look a bit more like Pascal. It did no one any good. You still couldn’t write Pascal and feed it to your C compiler, no one conversant with C could read your code, and it slowed learning proper C. Just bite the bullet and learn the language instead of doing a half-baked emulation for another language.
= is pretty similar to
julia> if (m = match(r"foo", "foobar")) !== nothing print(m) end RegexMatch("foo")
I’d be, for once, surprised if writing:
x = -5; x <-4 would return
nothing instead of
true, because I missed a space there, and there may be existing code that does miss it.
These operators exist on R (in both directions) and as I have never seen an assignment with an omitted space, I had never thought about this problem (and I wonder how they handle it on R and if such a mistake is common…). At least, no problem with a hypothetical one-character Unicode operator.
> x = -5 > x<-4 > x  4 > x < -4  FALSE
Julia usually raises a syntax error for ambiguous parses.
≟ could be an alias of
==, but I don’t think I’d ever want to use unicode for that specifically. I could see some value in creating a unicode alias for
deepcopy with assignment. That is, if the alias is
b ≍ a could mean
b = copy(a) or perhaps
b = deepcopy(a). Not sure if I would use that either.
The reason why python needs
:= is simple: python is not an expression-first language, which means that you cannot use assignment statements inside expressions. Hence, an extra syntax for Python is required to bind variables inside expressions.
Julia is born an expression-first language and has no such inconsistency – simply
= is enough.
Python could have lifted
= into an expression (and it has done for other statements) but wisely did not.
In Julia, using
= for assignment makes it possible to confuse
value = false if (value == x) # depends on equality
value = false if (value = x) # depends on x
Python doesn’t have this problem, which is good because in Python it would be much more severe, since everything behaves like a boolean under
if. This danger is the reason that people use Yoda conditions in some languages. (Yoda conditions aren’t generally used in Python because they’re not necessary.)
It’s not quite as widespread a problem as it looks since Julia will catch the case without parentheses, but
== are nonetheless uncomfortably close and it would be better to have more visual distinction.
In particular, see the section “Can this feature be a problem in Julia?”
I don’t think it’s so unlikely to have two boolean variables in a condition.
Edit: Nor is it uncommon to want parentheses for clarity.
Have you read the post at all?
I think this consideration is well covered by Julia.
Julia firstly needs the expressiveness. Unlike giving many syntactic restrictions to programmers by default, Julia needs to consider the convenience of metaprogramming, so that making inconsistent syntax rules for
:= is not that appealing in Julia.
If you want the same functionality(i.e., syntactic checking of
=) as Python’s, I think it should be implemented as a macro and provided by a library.
Yes, it says that writing
if (a == b) is unlikely (but I disagree), and points out (as I did above) that not using parens avoids the problem.
[Edited to fix “not”]
Maybe jzr means not only “top-level”
= in a condition?
if (a == b) & (c = d) & (e == f); 4 end
doesn’t do what I want for example. (If that’s what you mean @thautwarm ?)
It is often helpful to use parentheses to avoid confusion in, say,
a == b && c == d
to distinguish between
(a == b) && (c == d)
a == (b && c) == d
but the parentheses allow a bug to go unnoticed.