RFC: Make and & or aliases for && and ||.

[Ismael-VC]

This PR implements #5238

• :(a && b) == :(a and b) or :(a && b) != :(a and b)?

  • :(a && b) == :(a and b) is true

• Do we want to deprecate && and || or ?

  • This PR implements and and or as aliases for && and || respectively.

Special thanks to @TotalVerb for taking his mentorship! 👏

[Ismael-VC]

With this changes it seem to be good for adding tests now:

ismaelvc@toybox:~/vizen-juila$ ./julia
               _
   _       _ _(_)_     |  By greedy hackers for greedy hackers.
  (_)     | (_) (_)    |  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _' |  |
  | | |_| | | | (_| |  |  Version 0.6.0-dev.1801 (2016-12-31 01:28 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit 90df437 (0 days old master)
|__/                   |  x86_64-linux-gnu

julia> true and :foo
:foo

julia> :(a and b)
:(a && b)

[vchuravy]

Does this keep the short-circuiting behaviour of && for and?

Also I am against removing/deprecating && and ||

[TotalVerb]

Yes, it parses a and b exactly as a && b.

[Ismael-VC]

@vchuravy yes, as it is right now this PR implements and and or as aliases for && and || respectively, I've just added some tests, please let me know what do you think, thanks!

[Ismael-VC]

Could someone please cancel the previous CI tests, please? Thanks in advance!

[stevengj]

If we do this it should be one or the other, not both; synonyms in the language (excluding ASCII/Unicode synonyms) are just too confusing. But the plan would have to be to deprecate && and || in the next release, not this one, because Compat can't handle the deprecation right now and it will make backwards-compatibility a nightmare.

(Personally, I don't much care one way or the other how we spell it, but given how marginal the benefit of a rename seems — new users quickly get used to the spelling, and there's no way to please everyone anyway — I'd be happier leaving things as-is.)

[Ismael-VC]

Build failure on Mac seems unrelated.

[Ismael-VC]

@stevengj why can't Compat handle this right now?

[TotalVerb]

@compat(x and y) won't work on 0.5 and previous.

[stevengj]

@Ismael-VC, because and and or don't parse as operators in previous Julia versions. @compat is a macro, so it relies on the Julia parser. Hence @compat x and y cannot be used to get x && y in Julia ≤ 0.5 since x and y won't parse.

[TotalVerb]

We could have a string macro for that; compat"x and y" could expand to x && y in 0.5. That would be a departure from existing Compat behaviour though.

[JeffBezanson]

I vote -1 here. I don't think there is much benefit. It's generally good to avoid stealing words.

The tradeoff when using punctuation is that it looks highly visually distinct, but can also be unclear. In x && y I feel the && is a nice visual separator, but also isn't too obscure since && is pretty standard. x and y looks more like a homogeneous run of letters. It's also a slight negative that and and or are different lengths.

[stevengj]

@TotalVerb, wouldn't the string macro have to implement basically the whole 0.6 parser in order to work with arbitrary expressions?

[TotalVerb]

Good point. Then probably a deprecation at this stage is not practical.

[stevengj]

(@Ismael-VC, regardless of whether this is accepted, thanks for putting in the effort to make a PR. It's always easier to make a decision on things when there is actual code available to look at.)

[cormullion]

Nice job. For me "&&" and "||" are minor blemishes on Julia's typically readable and easy to understand syntax. At least you had a go! 😀

[p-i-]

Tendency is to prefer the familiar -- it creates a comfort zone. And departure from habit is often perceived as irritation. Therefore it is difficult to be impartial on account of our conditioned experience. So may we all be super-conscious of this phenomenon!!

I think JB's argument that && is visually distinct over and is eroded somewhat by the fact that syntax highlighting is becoming ubiquitous. and will get highlighted as a keyword. x and y will therefore not appear as a homogenous run of words.

In fact on account of highlighting, the argument now swings the other way: a > b and c would now hinge on the and, so it becomes visually clear that we are performing (a > b) and (c) rather than a > (b and c).

(It has been pointed out to me that not everyone uses syntax highlighting, however there is a clear trend towards it and one should act with an eye to the future).

&& and & were chosen many years before syntax highlighting or Unicode. The problem was that there just aren't enough symbols on the computer keyboard. It is rather ugly as there is no compelling logic that && should represent 'Logical AND' and & 'BITWISE AND' -- it was an arbitrary decision (and arguably the wrong one, as logical-AND is much more common, plus & has a use as 'and' in written English) and hence an extra thing to be learned, creating unnecessary scope for confusion (and bugs where the wrong operator is used).

Conversely, using and for Logical AND has a compelling supporting logic: true and false are the possible values of logical operators, both words. So it is attractive that the operators themselves should also be words.

[p-i-]

Shouldn't we be looking long-term to replace && with ∧ (from https://en.wikipedia.org/wiki/List_of_logic_symbols)? So we have and and ∧? (and a \and[TAB] completion for the latter).

Some of these logical symbols are obscure to computer programmers, but this is a direct result of keyboard layouts from many years ago. Maybe Julia can play a role in rectifying the situation? Maybe in 20 years all languages will be using standardised logic symbols and will look back upon all of this QWERTY nonsense the way we look at punchcards today...

[simonbyrne]

Shouldn't we be looking long-term to replace && with ∧

See #17472 and related discussion.

[JeffBezanson]

@p-i- Yes people have biases, but notation is largely a matter of convention anyway. It's hard to argue that one symbol is objectively better than another. I don't think && is so wonderful, but I think it's unproblematic and widely used.

[tknopp]

But we use words in other context without complaining about them: in, do, in future where.

[JeffBezanson]

Yes, that's fair; a general objection to words as syntax is not the key argument here. My impression is just that && is much more widely used in programming languages than and. Which languages use and and or? Is there evidence of a trend in that direction?

[jtravs]

@p-i- I think this is a perfect example of how having an actual PR for a proposal really concentrates minds in a way that endless discussions do not. The fact that this change can now be obtained by simply pressing a merge button makes the discussion here much more important.

[johnmyleswhite]

I think @Ismael-VC should feel very proud of his work on this PR even if it doesn't get merged. It's impressive work and deserves respect, whether or not people agree on the design.

[JeffBezanson]

Nobody is proposing to ease learning at some future cost.

Yes, but I feel this is still missing the point that && syntax is very widespread, and you aren't going to be able to hide it from people forever.

"Copying C syntax" isn't what it once was. Globally, a pretty strong consensus has emerged against certain aspects of C syntax, for example using for x in y instead of C's for, the precedence of bit shift operators, type declaration syntax, semicolons at the ends of lines, and parenthesizing conditions. However I don't really see this happening for && and ||. New languages continue to use them. I suspect there are reasons to like them other than legacy. I like that they're the same length and are very easy to spot in code. There is also a slight preference for languages to "steal" punctuation instead of words. Given that it's a possible operator, what else would you use && for? Now, I agree none of these arguments are super strong, but I don't envision massive benefits pouring in for using and either.

[waldyrious]

I think the sentiment many have expressed in this thread stems from one of the hallmarks of Julia that attracted so many people to it. Quoting from the the original blog post:

We want a language (...) with obvious, familiar mathematical notation like Matlab. We want something (...) that is dirt simple to learn, yet keeps the most serious hackers happy.
(...)
We want the power without the layers of impenetrable complexity. (...) Despite all this power, we want the language to be simple and clean.

I don't think I need to emphasize the parts that reflect the spirit of this proposal. As @tknopp said above, "we currently have the chance to make changes that will never be made after [1.0]." It seems to me that this syntax change certainly fits the both overall style of Julia code, and the principles of code clarity and approachability.

[JeffBezanson]

&& isn't an example of a "layer of impenetrable complexity". Also, several mathematical languages, not just systems languages, have used && and ||.

[tknopp]

@JeffBezanson: Then please close this to indicate that this is not going to happen. Sometimes better to draw a clear decision under the discussion of this and #5238.

[p-i-]

It's worth questioning how && emerged over and in the early days. It is almost certainly because C predates colour displays (as do I, sigh!). Therefore it was important that an operator not be confused with a variable name: foo and bar just looks like three words without the benefit of syntax highlighting.

And in that case, I would prefer [WORD] [SYMBOL] [WORD]. But the reality is that nowadays syntax highlighting is generally available, which makes the operator stand out as a keyword.

Maybe if we merge @KristofferC 's color-prompt... :)

Having grown up with C's && and switching to Python only a few years back, it took only a little time before I started to prefer and. I wonder if there's anyone out there that has had substantial exposure to both but still prefers &&.

It's difficult to know which arguments for and against are ultimately motivated by a defensive post-rationalisation of something that has become instinctual.

Well, Julia is a fantastic technology regardless of surface syntax scuffles, and I am in awe of the piercing minds that continue to crystallise structure. I hope that I have the sharpness, dedication and time to contribute in the future and @Ismael-VC 's work in putting this together has been inspiring (especially watching @TotalVerb mentor him through the process on Gitter). Watching this community work together is an effective antidote to something I cannot quite put my finger on.

[kmsquire]

Having grown up with C's && and switching to Python only a few years back, it took only a little time before I started to prefer and. I wonder if there's anyone out there that has had substantial exposure to both but still prefers &&.

I want to second this statement. I still do most of my work programming in Python, and even though I really miss much of the performance and power of Julia, part of the reason I haven't pushed Julia more is that I don't find it quite as natural, so I find it difficult to push others to switch. The and/or vs &&/|| issue is one small part of this (and I promise I'll do my best to document others when I can make the time, hopefully well before Julia 1.0). And despite this, Julia is still my go-to language, when I have a choice.

I'll be okay if this PR doesn't get in, of course, but I agree with the general arguments and goals of this PR and its proponents.

[mpastell]

I have used a lot Python and don't miss and and or at all in Julia. I still think code is easier to read when you have operators instead of words even with syntax highlighting.

I do write some embedded C and C++ for data analysis as well, maybe my prefence would be different if I didn't.

[clarkevans]

There is perhaps a reason to support and/or besides aesthetic preference. Many of the languages (esp C, C++, Rust) that use || and && above are system languages that have corresponding bitwise operators (| and &). Being a scientific data processing language, Julia may find these symbols, | and &, to be more useful as pipeline construction or parallel processing indicators. In which case, there is less need for correspondence, making and / or a more suitable choice.

One thing I'd rather not have is 2 ways to do it -- then the whole community has to learn both ways. I definitely miss and/or in Julia (as opposed to Python), but I haven't done "C" programming in decades.

[stevengj]

(@clarkevans, Julia does use & and | as bitwise operators.)

[bramtayl]

It seems a bit half handed to change && and || but not & and |. What about andthen and orelse for && and ||, and and and or for & and |? This would fit in nicely with control-flow usage as well:

condition andthen error

instead of

condition && error

Credit to https://discourse.julialang.org/t/proposal-then-else-syntax-to-replace-short-circuiting/1323/46

[kmsquire]

@bramtayl, I think part of the point here is to better distinguish between boolean and bitwise operations.

(Ignoring the fact that this probably doesn't have enough support to be merged… )

Cheers!

[holocronweaver]

I support this change. I find the word-notation easier to read at a glance and more intuitive to new programmers. It is also easier to type, involving no far stretching on a QWERTY layout.

As has been mentioned, C has both notations via iso646 and ISO C++ has both built into the language. I have yet to meet anyone confused or burdened by having both choices. Even novice C++ coders I train pick it up easily, usually preferring and and or. So I think having both notations is fine.

Adding not as an alias for ! would make sense as well. The ! is the culprit of many a time-wasting bug due to its slenderness being all too easy to overlook while speed reading code. xor would be great too, especially since the Julia notation $ is unusual and unintuitive.

[stevengj]

@holocronweaver, $ for xor was deprecated in 0.6 (#18977). (This wasn't a big deal because hardly any Julia code uses xor. The same cannot be said for && and !.)

[StefanKarpinski]

Yeah, seems like we're not going to do this.

[ararslan]

Though I'll reiterate that you did great work here, @Ismael-VC, and you should be proud of it even though it didn't make it in.

[StefanKarpinski]

Yes, thank you @Ismael-VC – sorry it came to naught but not for nothing!

[Ismael-VC]

I understand.

I also learned a lot from this, and just wish I had more time to keep contributing.

Thanks guys, I admire your work. Julia is amazing.

[Ismael-VC]

@martinholters could we reopen this PR, I can change the title to Replace && and || with and and or and make them not aliases.

[waldyrious]

@Ismael-VC If I understand the discussion at #5238, when Stefan said

this gets done if someone does it

he was talking about

reserving the and, or and not syntax.

This is also what @martinholters stood for, when he reopened that issue:

deprecate any use of and and or so that we can postpone the decision without risking to break anyones code later on.

So the uncontroversial action at this point would be to implement the reservation (as is currently done e.g. for ++, IIUC), rather than replacing && and || with and and or right now, which would most likely be rejected.

[martinholters]

Yea, I'd prefer to have discussion centralized at #5238 and in case a decision is reached that we want something that is sufficiently close to what this PR implements, then we can reopen it.

[Ismael-VC]

Yes, sorry for the noise, Martin and Stefan clarified this to me in #5238 shortly after I asked for reopening this PR.