Add `and`, `or`, `not` and `xor` methods to Boolean

The idea is to be able to use and, or, etc in control expressions instead of &&, ||, etc.

In terms of implementation the only catch is to also change the Language Specification/Compiler to ensure the proper precedence.

Advantages:

  • Easier to type
  • Easier to read
  • Very easy to implement, just 4 methods forwarding to the corresponding operators. Plus the code in the compiler to ensure the correct precedence.
  • Diminishes barrier to entry very slightly

Disadvantages:

  • Two ways of computing boolean expressions

PS: I’m not suggesting making and, or, not and xor keywords.

2 Likes

I wonder if it would be too casual to have precedence defined in terms of aliases.

I don’t remember what mechanism they introduced to say that /: is an alias of foldLeft, but that mechanism could imply that the alnum operator has the precedence of the symbolic operator. Possibly that assumes there is only one canonical symbolic operator.

Maybe the mechanism was to say that a symbolic operator has a canonical alnum name instead of conversely. So they should change that.

2 Likes

Makes sense, especially in the context of the proposed @alpha annotation in Dotty. I wonder if that annotation can/should be retro-fitted into 2.14…

1 Like

I think this part is by far the biggest disadvantage and it easily outweighs the listed advantages.

1 Like

Changing the Language Specification is easy. Changing the compiler resumes to changing the Precendence class to check not only the first char but the full name if the infix operator is being called upon boolean.

I’m not so much worried about the difficulty of changing it than the added inconsistency in the language.

Also, I think that right now precedence is handled purely in the parser. If you want to special case it to Booleans you’d have to hack the syntax tree in the typer. And that would create an even bigger inconsistency.

1 Like

I am strongly opposed. One must never, never change the precedence of anything in a well established language. The potential for silent breakage of code is too great.

Also adding a second way to do stuff is bad, even worse when it’s on primitives.

4 Likes

In the context of the @alpha proposal, this makes less sense, not more. With @alpha we would add the annotation on the existing symbolic operators. We wouldn’t add alphanumeric aliases.

sjrd

      SIP Committee member




    September 16

I am strongly opposed. One must never, never change the precedence of anything in a well established language. The potential for silent breakage of code is too great.

Also adding a second way to do stuff is bad, even worse when it’s on primitives.

I hope you can convince the Dotty team of that.

1 Like

Adding new methods and attaching them to existing precedence levels shouldn’t cause silent breakage. But fair enough I have very little experience with compilers so I can’t see the problems.

&& and || are symbolic methods, which in dotty would mean they would need the @alpha annotation. Of course that is unrelated to adding alphanumeric aliases. And its also weird to do so since @alpha only exists for documentation and interoperability with other JVM languages (which will probably already support && and ||).

Since we are talking about dotty I would also think this change would go nicely with brace-less syntax for control expressions.

I accept this is not worth to add to Scala 2, but for Dotty?

If I’m already using extension methods with these names, and you add these as primitives with the appropriate precedence (and over or), you may break my code silently. For example if I had x or y and z, which used to parse as (x or y) and z but would now parse as x or (y and z).

3 Likes

Fair enough, in the general case you can break things. However in this specific scenario if a developer created extension methods on Boolean with those specific names and did not account for precedence, well I’m sorry for his code base and coding skills.

I haven’t tried it yet but In Dotty with extensions methods and inline this should be implementable with just adding the methods, aka, without even having to touch the precedence:

inline def (first: Boolean) and (second: => Boolean): Boolean = first && second

Of course implementing them directly on the Boolean class would reduce the overhead just to inlining.

You don’t get to chose the precedence of alphanumeric methods in Scala. Them being inline does not change anything to their precedence.

I’ve actually used such extension methods, and normally used parentheses to make all usages unambiguous. But it’s possible I haven’t applied that convention completely consistently, and I wouldn’t like my code to break in these cases.

3 Likes

You are correct. Inlining won’t work. I was naively thinking this x or y and z would be inlined to x || y && z. But in practice it will probably be inlined to (x || y) && z.

That is a risky move. Just one missing parenthesis and your logic would go wrong.

If I understand correctly you don’t want to break the cases where you forgot to apply the convention. Thus keeping your common law feature. Adding the methods to Boolean would fix your original mistake.

Well at least I’m not the only one who prefers and, or to &&, ||.

I personally prefer the symbols notation to the words.

Me too, personally, in fact I wish dotty had taken the opportunity to switch the semantics of the single & and doubled && operators. Break ALL the things, to match my preference.

Although this proposal is a bad idea, OTOH that only forces one to think further outside the box.

Precedence is defined syntactically, but it’s unthinkable that anyone would misunderstand

x or y and z

in a Boolean context.

The folks who write SQL prefer those CAPS, and Java folks love the CAPS for constants inherited from C, which don’t give me any pleasure, but perhaps there is a convention or syntactic hint that would distinguish this Boolean and from similar-sounding methods on other types.

If and is a special “operator alias” for &&, maybe give it a special syntax, *and* which would be displayed in IDEs and editors in boldface and oh wait that’s italics. OK, another use for underscore, _and_ is and oh that also renders italics? and is double star **and**?

By contrast, people do ask why do I need parens around this for or match expression? The answer there is never adequate to ordinary understanding.