+1
I would really like to see this happen.
More readable like end used for indexing.

+1
On Dec 27, 2013 1:06 PM, "GaborOszlanyi" [email protected] wrote:

+1
I would really like to see this happen.
More readable like end used for indexing.

—
Reply to this email directly or view it on GitHubhttps://github.com/JuliaLang/julia/issues/5238#issuecomment-31280112
.

I like this suggestion too.

I'm a bit surprised by the groundswell of support this is getting. I've always felt that the spelled out operators were much more intuitive for control flow, but I didn't realize the feeling was widespread.

I was not a fan when you made this proposition, but I must say after some more thinking it also makes much sense to me. These are really control flow operators, in contrast with all others, which use symbols rather than text. This may reduce the confusion with & and |.

I've noticed that the languages which provide and and or (Perl, Ruby, Lua -- for the ones I checked) also provide not (Lua even does not offer !). My first reaction is that I don't like it, since it's redundant with !. But maybe there's a strong reason why these languages chose to do so.

I personally like not a lot, but don't think that switching to not offers anything like the reduction in ambiguity that using and and or provide.

not is not a short circuit/control flow operation either, and I always struggle with how to read it with regards to associativity. The only place I like it in Pyhton is the if not ... but that is because I read it as a control flow operation.

+1

Can also be added XOR as short circuit ?
And short circuit version of the inverted versions (XNOR,NAND,NOR) ?

XOR is never short-circuitable. The other ones can be trivially written with ! plus the and and or operators.

+1
I'll point out that in Ruby, there's constant confusion about && vs 'and' (http://devblog.avdi.org/2010/08/02/using-and-and-or-in-ruby/), so it would be good if we kept in mind the rational that Ruby uses to have both sets of operators and decide whether its worth the confusion or if && should be removed completely in favor of 'and'.

I would prefer for and and or to have super-low precedence like they do in Perl and Ruby so that you can write things like

k <= n and k *= 2

Sometimes you want to assign the boolean result to something:

cond = f() && g()

Which seems to conflict with that.

Well, that's precisely why Ruby and Perl have both sets of operators with different precedence. Not advocating for that, but just saying. I'm not sure how common that usage actually is, whereas grepping through our code reveals a lot of k <= n && (k *= 2) kinds of things.

Firstly, I'm also for and and or.
I see that lowest four precedence groups in Julia right now are

1. Assignments including += etc., :=, =>, and ~
2. The ternary operator ?
3. ||
4. &&

I think that this makes good sense (not sure about ~, but that's beside the point). Logical and and or are useful both as right hand side of assignments and condition of ?. If you are going to use either an assignment or ternary operator as argument to and or or, I think you know that you are doing something unusual and that parentheses are in order.

Btw, I think that a lot of people would expect that a language that uses and and or for logical operations would use not for logical negation. But if we have good reason to keep !, that might be ok. (I guess that ! is not strictly just logical negation, at least if #4892 is implemented is merged.)

I would be a little sad about not instead of !, but I'll go with whatever here.

I really don't think not is analogous at all – and and or are control flow operators, not functions, whereas ! is just a function.

I agree with Stefan. The only thing not really gets you is not having to use as many parenthesis. I think that's a separate issue.

I was just talking about initial expectations of new users. But I think
there seems to be a sound reason to be able to keep !

I'd like to be contrary. Quite a few languages use && and ||, including all the ones I have used with any regularity, and those are always short-circuit. With and/or I'd have no intuitive expectation whether they short-circuit or not. I also like how && and || are clearly visually separated from variable names and numbers.

The table at http://en.wikipedia.org/wiki/Short-circuit_evaluation may have some relevance for this discussion.

As someone coming from the Python world I'm surprised to find myself in agreement with @GunnarFarneback. Lately I've found that the english conditionals (and,or,not) often lead to me writing incorrect code that I naively expect to work (because it makes sense in english) and then having to scratch my head for a few seconds while I mentally convert from english to logical statements before realizing my error. That said I'm not particularly biased in either direction; just putting in my 2¢.

I'm also for and and or

+1

+1
have both operators
and and or with weak precedence
I would argue that cond = f() && g() should be written cond = (f() && g()).
I also support the use of not with weak precedence on grounds that !, which has strong precedence in every context I've seen, requires if !(something and something) which I dislike on some deep, irrational, and unchangeable level. I also feel like ! is hard to see sometimes. I am also ignorant to he origin of ! but feel that it has a more rightful place as factorial operator on integers--thus a preference for matlab's ~ syntax.

@johnmyleswhite this issue be closed? I think the ship has sailed on this one.

:(

short circuit that frowny face

I think we should still consider this. A lot of people seem to dislike using && and || the way we're using them and would prefer and and or. There's also the issue of precedence, which makes && and || somewhat awkward. We could move to a future where && and || require both operands to be boolean and and and or do what && and || currently do but with lower precedence so that you can write x == nothing and x = 0 and such. Either that or introduce a different one-line conditional syntax like x = 0 if x == nothing.

The last syntax x = 0 if x == nothing has some of the problems IMO that the suggestion in https://groups.google.com/forum/#!topic/julia-dev/cnmLcNg8h0Q does.
Are the two following options so horrible that Julia needs post-conditionals?

    if x == nothing ; x = 0 ; end

or

   x == nothing && (x = 0)

That said, just as I wouldn't mind seeing a repeat ; expr(s) ; until cond construct in Julia (but can live without it), I don't see anything wrong with having and and or added to Julia.
They do seem to fit in better with julia syntax than using the borrowed from C && and ||.

I think we should still consider this.

+1

I was surprised by assignment being lower precedence than ||, so I came in search of previous discussion and found this issue. It's not a big deal, but those parentheses do look out of place to me. It took me a while (several seconds, I think, and a test in REPL) to find out which assignment location was invalid. - The error message indicated the line past the end of the function definition.

isempty(o) || (m.over[s][NULL] = o)

In contrast, the parentheses in cond = (f() && g()) look all right to me. I think I would use them anyway.

For what it's worth, I would also prefer and and or.

+1 from me too.

Response is almost unanimously positive in favour of and etc. I count two opinions against, one indifferent, a couple unspecified and everyone else (15 or more) in favour.

One argument against (more difficult to read) I think is incorrect. The argument is that foo and bar is more difficult to read than foo && bar on account of 3 words vs word SYMBOL word. However everyone is using syntax highlighting, and in this case the reverse happens. and is coloured as a keyword, so a<1 and b>3 will actually colour in favour of visually splitting up the left and right subexpressions, whereas a<1 && b>3 all three operators will be the same colour, cue potential operator-precedence-head-scratching.

An argument _for_ that hasn't yet been presented is that there is an elegant consistency to boolean operators being words, as the result of the operation is either true or false, i.e. also a word. So it's very easy for a beginner to memorise & vs and for bitwise versus logical. It's much more difficult to memorise & vs &&, as it appears an arbitrary assignation. Guaranteed beginners will be using & incorrectly, as & conveys the word and in English. This might cause precedence bugs(?).

Another possible argument _for_ would be that the brain naturally parses {BUNCH OF SYMBOLS} word {BUNCH OF SYMBOLS}.

Why not just switch? Now is always the best time to do it, it is never going to be easier than now. It's not exactly difficult to fix code that currently uses &&.

Have and or not xor maybe nand just for completeness?? I don't mind the idea of keeping !. Let the programmer choose when to use which. Nothing wrong with that! Having said, ! already has a use in foo! style functions, so there is some "minimise symbol reuse" argument.

@StefanKarpinski there seems to be consensus in favor dating back from 2013, I could try to implement this, but I'm worried if this will be considered at all, since this issue hasn't been closed I would assume this is still open for discussion? Using this words instead of symbols will go nicely with isa being an infix operator also, same as with true, false, end, etc. It seems more consistent and readable this way.

+1

Just moving into Julia from Python. Seems Julia is in danger of getting into symbol overflow. For the sake of human readable code, I strongly support and and or

Supporting not keyword could also improve code readability.

Should we deprecate/forbid use of and and or (and possibly not) in 0.7/1.0, respectively, to be able to add these later on in case we decide to indeed like them?

I'd be down with that. I bet @JeffBezanson is against, but we if we disallow now we can always change our minds later and allow it, whereas we can't go in the other direction. It might also be helpful to be able to give a simple "Use && instead of and" error message to users who try Python-style operators.

I think that'd be great!

Reopening and adding to milestone to make sure we don't forget.

I don't understand the intent of the milestone, we are going to add and and or? we are reconsidering it? looking for another use of this? Or you mean you are going to add deprecation like warnings, so people coming from Python know to use && instead of and?

I had https://github.com/JuliaLang/julia/pull/19788 in which they were aliases, but I can change that to replace them.

The milestone should mean: Reach a decision. Or, if we cannot reach a decision in time, deprecate any use of and and or so that we can postpone the decision without risking to break anyones code later on.

I understand that given aspiration to freeze code in a few weeks it may be to late to re-open this can of worms now (and I appreciate the idea of adding depreciations to leave door open for the future), but one thought:

When this first came up for discussion (2013), I think the Julia community was primarily developers -- people with strong CS backgrounds who were more than used to using && and ||. I _suspect_ that the people who might appreciate and and or most are applied users who aren't as comfortable with ascii salads and who have yet to spend enough time in older languages to become entirely used to && and ||. It might be interested to see how people felt about this if we polled current Julia users (especially if we brought it up on discourse where more non-developers are likely to see it).

What's been proposed is reserving the and, or and not syntax. If we do that, we can add these as operators at any point in the 1.x timeline. No further discussion is required for now.

I'd be fine with parsing these as permanent syntax errors, as we do with **. But I'm still very, very against giving them any kind of meaning otherwise.

I also find it unfortunate that we're digging up old issues for which a decision has already been reached, especially so close to 1.0.

To be clear: this gets done if someone does it.

Thanks for the clarification! :D

It seems very silly to me to bother parsing them and prohibiting other use, and nevertheless make it a syntax error. I think most people would rather not have situation where and and or are reserved words (i.e. not usable in contexts like @stackeval 1 0 and 1 or) yet do nothing useful. I would suggest that either they not be parsed at all, or be parsed as aliases (which is not unusual, as C and Ruby do that).

We've already decided not to parse them as aliases, that's why the PR was closed. So +1 for not parsing them at all.

At the risk of rehashing this discussion which has been had ad nauseum, I'll note that regarding C and Ruby, using and and or in C is very uncommon in my experience, and the most common Ruby style guides require && and || instead of and and or.

IMHO: seems like the original debates were rather divided, and adding this protection simply leaves space for the community to revisit it in the future it they'd like.

I don't have any idea why this was reopened.

A Julia dialect with syntactic features like this one could be done using JuliaParser.jl easily, once the internal and meta-programming APIs stabilize, can't wait for it! :smile:

For those coming to this issue without having followed what has happened: Although the idea of using and and or gathered a fair amount of support *), the first PR to approach the issue - #19788 - mainly led to an inconclusive discussion of whether and and or should be direct replacements for && and || or should have slightly different semantics, e.g. with regards to precedence, but just making them aliases was deemed unwanted. PR #24965 would have reserved the keywords (along with not), to allow giving them a meaning during the 1.x cycle. However, discussion during a triage call resulted in disapproval, so the earliest point at which this could be reconsidered is for 2.0. (And one would probably need to make a really compelling case for the change to happen then.)

*) It seems as if the proposed change is less popular with more influential/"core" developers, so just looking at the number of 👍s may be misleading, though.

I hope I didn't over-simplify and got things decently right. Apologies if I didn't.

so the earliest point at which this could be reconsidered is for 2.0. (And one would probably need to make a really compelling case for the change to happen then.)

I don't see why it would ever happen if we've decided multiple times now not to do it. I hope we can avoid digging this issue up again for every major release.

If Julia sticks around long enough to compete with Python, I can guarantee this will come up more and more. Many Python users don't want to return to C syntax. It's one of the many reasons Python is so popular: easy to learn, addicting to use, you won't want to go back the old way of doing things.

New language designers often claim they want user-friendly syntax, yet they tend to get lost in fancy features only a tiny subset of users will ever want or use, while overlooking simple tweaks that could drive adoption.

Case in point: bizarre Unicode operators are supported, but not natural language and and or.

R also uses && and || and 1-indexing. It's not just older (or lower level languages like C). I'm indifferent to which to use but it is not more difficult: I've taught both R and Python to complete beginners (no programming difference) and this is not what they struggled with. Usually the underlying concepts were more important and took more time to learn than the symbols or words used to write the code. "User-friendly" and "intuitive" syntax to you as a R, Python, C, etc user will be different simply because of what you are already familiar with. That is not the case for absolute beginners who we should be more concerned with here since I think those with experience programming in other languages have the experience and expertise to handle the different conventions in a new language.

The only reason that seems to have been raised here is that Python uses and and or and people like that. Is that worth the trouble to change over? Julia is not Python and should not try to be. We already have Python. To give anyone motivation to switch over to a new language, it should be different. New users of Julia may not be Python programmers, they may have experience with a different language (or none at all if it becomes popular enough).

I recognize this probably a dead issue, but in reply to @TomKellyGenetics, I would suggest that IMHO many of us would argue R qualifies as "older" and it not particularly user friendly... And while I agree that with beginners, && operators is "not what they struggled with", I do think most student's I've taught find english language operators (and, or) more familiar and readable whether they are Python users or not.

R also uses && and || and 1-indexing. It's not just older (or lower level )languages like C).

I was referring to C-like languages, i.e. languages that heavily borrow syntax from C, usually with the self-fulfilling argument of 'it is the syntax every other language uses'. R syntax is rather C-like, though it diverges here and there. Julia is more Fortran-like than C-like, though there is some overlap.

I've taught both R and Python to complete beginners (no programming difference) and this is not what they struggled with.

IME students new to programming struggle with syntax on top of everything else, it's death by a thousand cuts. Programming is alien, and choosing abstract symbols over natural language makes it even more foreign and easy to forget. I often hear beginners in C-like languages ask things like, "How do you write 'or' again?"
But natural language in programming is not just an issue for beginners. Even experienced programmers are more likely to miss a ! over a not, and many find it easier to speed read and type or and and over || and &&.

Julia is not Python and should not try to be. We already have Python. To give anyone motivation to switch over to a new language, it should be different.

Julia is not C or Fortran either. The vast majority of popular languages are C-like, so standing out usually means doing something different from C. I actually like Fortran, C and their descendants, use them all the time, but in some places they fall short and I think we can do better. Using more natural language is one way. It's worth noting that Fortran 77 and up use .not., .and. and .or. to good effect. In this sense I actually want Julia to be more Fortran-like, less C-like!

This issue has been resolved; and and or are allowed as identifiers and we will continue to use && and || for control flow. I'm not sure why this is still being discussed.

There is a tendency to over-rate the importance of superficial syntax issues, since they are highly visible, easy to discuss, and their implications are usually clear. In another sphere, a language is considered unusable unless code blocks are surrounded by curly braces, in which case both julia and python are beyond the pale.

I think it's debatable whether a and b is indeed more readable than a && b. && stands out more. The fact that || and && are the same length can also lead to nicer formatting. One of the reasons operator symbols like a = b and a + b work so well is that they add visual structure over something like set a to b. a[i] or element i of a?

you won't want to go back the old way of doing things.

To me, the old way of doing things is manual memory management and weak support for polymorphism, not the spelling of &&.

Julia has a few natural language expressions, such as for a in [1, 2, 3]. This reads better and is more intuitive than for a = [1, 2, 3], which Julia also supports. I certainly wouldn't suggest we provide natural language alternatives for all symbolic operators, only the few that make Julia more intuitive and readable.

FWIW, I voted to adopt both sets of operators, to ease adoption and give users style choices. In C++ projects where people use both it has never bothered me. I see no harm in it, only benefits.

Overall I love the direction Julia's syntax has gone. A great balance between natural language and symbols, proving a numeric language can excel at general purpose programming. Can't wait to see how it grows and develops. Which is my way of saying adding the natural language operators is technically backwards compatible. :grin:

I will give a shot at reserving or, and and not for possible future use, and to issue a warning / suggestion to use the corresponding symbols. Should I do this in Julia 0.7, 1.0, or both?

24965 ?

Ah, missed that, thanks! I guess not reserving keywords doesn't prevent supporting these keywords in the future.

Sorry, read all discussion, but still didn't got it, how can I use and, or in Julia now ?

You can't