I think it makes sense to set := and =? as aliases for = and == respectively. The first one helps those coming from Python or Pascal, where := is valid syntax, and can also improve the readability of code. =? strikes me as more intuitive and readable than ==. I think it still makes sense to keep = and == for those coming from more traditional languages, though.
1 Like
Is it? Seems to me pretty much the same as in Julia:
Python 3.8.3 (default, May 19 2020, 18:47:26)
[GCC 7.3.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> x = 1
>>> x
1
>>> x := 1
File "<stdin>", line 1
x := 1
^
SyntaxError: invalid syntax
>>> 1 =? 2
File "<stdin>", line 1
1 =? 2
^
SyntaxError: invalid syntax
>>> x == 1
True
>>>
1 Like
:= means something pretty different from = in Python (3.8 and higher): PEP 572 â Assignment Expressions | peps.python.org. I think it would be pretty confusing to make it an alias of =
4 Likes
Stefan once suggested an idea that Iâm a fan of, of letting a := b be similar to
var"#tmp#1231#" = b
a::typeof(var"#tmp#1231#") = var"#tmp#1231#"
That is, we could use this syntax for making type stable declarations.
One the one hand, this syntax is strictly limiting â it doesnât let you do anything you couldnât do before, instead simply taking possibilities away.
On the other hand, most of us (myself included) have spent a lot of time hunting for type instabilities, particularly when using lots of closures, so a convenient syntax for this could be a time saver.
My point here though is that if we add new syntax, it should have definite advantages.
23 Likes
It does mean something different in Python, where = has no return value; there, := combines assignment and returns the right-hand side.
(x:=2)**2
Out[1]: 4
x
Out[2]: 2
(x=2)**2
File "<ipython-input-3-25b7a63e2328>", line 1
(x=2)**2
^
SyntaxError: invalid syntax
In Julia, = means the same thing as := does in Python:
julia> (x=2)^2
4
julia> x
2
= behaves like := does in Python, so making := an alias of = will result in the same behavior for := in both Julia and Python. The only difference Iâm aware of here is that := would not throw an error when used outside of a function or expression, but that shouldnât cause any problems for someone coming in from Python (although it could theoretically cause trouble when going in the opposite direction, which strikes me as a sensible argument against).
This seems like it could cause some potential confusion with languages like Pascal or Python where := does not imply type stability; Iâd suggest a keyword like stable or similar (e.g. stable x = 2.0) to avoid this confusion.
Both suggested aliases do have a significant advantage, namely improving readability of code by clearly distinguishing assignment from evaluation.
1 Like
That example is only worth it if itâs very succinct syntax, otherwise
macro stable(ex)
Meta.isexpr(ex, :(=), 2) || throw(ArgumentError("`@stable` macro requires assignment."))
quote
tmp = $(esc(ex.args[2]))
$(esc(ex.args[1]))::typeof(tmp) = tmp
end
end
is easy enough to write.
Iâd prefer not having syntax that (a) has no advantage over what someone can do in a library/with their own code (e.g. @stable vs stable), or is useless like := being an alias to =.
5 Likes
5 Likes
Saying := is useless because you have = already feels like saying x â
y is useless because we already have dot(x, y). They might both do the same thing, but one is a lot more readable and aligns more closely with notation in theoretical work/mathematics. := is commonly used in computer science papers for assignment because it is unambiguous, and itâs more readable than =; dot is there for accessibility (for those who donât know how to use Unicode). I donât see a reason to treat â (or := to avoid Unicode) any differently.
As for the comment on a stable keyword, that seems like a reasonable comment, but I donât see why youâre shooting down your own proposal.
2 Likes
The difference is that â
is not just Unicode, but also an infix operator with syntactical sugar. To make := an alias of = would just be noise. (Imagine reading code that mixes the two.) Also, it is not necessarily the goal of Julia to emulate Python. Any language should reasonably consider more fundamental reasons to adopt a particular syntax.
Now, there is serious argument that = is just poor syntax, dating back at least 60 years. Niklaus Wirth (and probably others earlier) argued as such, and we had := as early as ALGOL (and Pascal as you note). The arguments still hold today, and might better support your proposal here, especially with := replacing =. However, this would be quite the breaking change, so it would be more apt to propose for something like Julia 2.0. No such change, no matter how wonderful, would be considered before that version.
Your idea for =? is also stronger as a replacement. But then does your issue with == disappear once = is gone? Itâs unclear whether you would keep <, or turn that into <?. It might help if you clarify your suggestion. Julia is not yet taking the approach of Python Extension Proposals (PEPs), but any big change probably needs a very seriously argued basis.
9 Likes
I certainly donât speak for everyone else, but I would conjecture that many here disagree that your proposals are âmore readableâ
9 Likes
Aliasing == to =? would seem to also demand aliasing === to ==?, but this invites further confusion, because ==? might read to some as an alias of ==.
And then wouldnât users come to expect >=? and the like as well?
I donât come from a CS background, but it seems to me that a maxim of âmore synonyms is always goodâ could invite considerable bloat into the language down the line. There will always be someone who favors adding a new alias you havenât thought of. Why not alias ⥠as well? (Oh, looks like that one is already aliased to ===.) What about â (in LaTeX, \triangleq)?
2 Likes
I wish that from the beginning := were assignment, = were equality test, and == were identity test. Then negation would be accomplished by simply prepending a !, just like with all other operators. That would also help with this ! for infix operators ¡ Issue #25512 ¡ JuliaLang/julia ¡ GitHub
Unfortunately, itâs too late to fix now, and adding more superfluous syntax would just be confusing.
14 Likes
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.
10 Likes
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.
7 Likes
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 (â versus ==), making me often choose to test inequalities to avoid mistakes (confusion with =)âŚ
1 Like
It was very controversial during the proposal process and many Pythonistas still consider that change a mistake.
3 Likes
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.
5 Likes
= is pretty similar to := already
julia> if (m = match(r"foo", "foobar")) !== nothing
print(m)
end
RegexMatch("foo")
3 Likes