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.
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.
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.
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.
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.
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 ||).
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).
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.
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 &&, ||.
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.
