[
https://issues.apache.org/jira/browse/GROOVY-11238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790326#comment-17790326
]
ASF GitHub Bot commented on GROOVY-11238:
-----------------------------------------
daniellansun commented on code in PR #1999:
URL: https://github.com/apache/groovy/pull/1999#discussion_r1406945262
##########
src/antlr/GroovyParser.g4:
##########
@@ -848,6 +848,9 @@ expression
// logical or (||) (level 13)
| left=expression nls op=OR nls right=expression
#logicalOrExprAlt
+ // implication (==>) (level 13.5)
+ | <assoc=right> left=expression nls op=IMPLIES nls right=expression
#implicationExprAlt
Review Comment:
Logical Operators are left-associative, I think we do not need the assoc
option.
For example,
a ==> b ==> c
should be parsed as
(a ==> b) ==> c
See also
https://stackoverflow.com/questions/39317938/associativity-and-precedence-of-java-operators-in-antlrv4-grammar
> Logical implication operator revisited
> --------------------------------------
>
> Key: GROOVY-11238
> URL: https://issues.apache.org/jira/browse/GROOVY-11238
> Project: Groovy
> Issue Type: New Feature
> Reporter: Paul King
> Assignee: Paul King
> Priority: Major
> Fix For: 5.x
>
>
> Some languages like Racket, Eiffel and Dafny have an implication operator.
> Others like Scala and Python rely on the "<=" operator for Booleans, though
> that is not short-circuiting. Groovy has an "implies" method (also
> short-circuiting) and we explored some time back about supporting an
> implication operator. At the time, we decided it wasn't needed, after all, "A
> implies B" is the same as "!A || B". In a lot of programming scenarios, the
> existing operators work well and are well known, but there are some cases
> like preconditions, postconditions, invariants and other logical expressions
> where the implication operator would read better. Since the groovy-contracts
> module supports such expressions and testing frameworks like jqwik also have
> logical expressions, this issue is to explore that possibility again.
> Earlier, we had considered "=>" as the operator (like Racket) but that was
> considered too easy to confuse with "<=" and ">=". It also conflicted with
> the early lambda syntax (though that isn't relevant now). So, I suggest we
> use "==>" like Dafny (and what has been proposed for Scala).
> Here is what some jqwik tests would look like:
> {code:groovy}
> @Property(tries=10)
> boolean 'only zero is the same as the negative of itself'(@ForAll int i) {
> i == 0 ==> i == -i
> }
> @Property(tries=100)
> boolean 'an odd number squared is still odd'(@ForAll int n) {
> n % 2 == 1 ==> (n ** 2) % 2 == 1
> }
> @Property(tries=100)
> boolean 'abs of a positive integer is itself'(@ForAll int i) {
> i >= 0 ==> i.abs() == i
> }
> {code}
> Here is an example with DBC:
> {code:groovy}
> @Requires({ result >= 0
> && (n >= 0 ==> result == n)
> && (n < 0 ==> result == -n)})
> int myAbs(int n) {
> n.abs()
> }
> {code}
> This is in a form that could be sent to a proof checking framework (though we
> have no such integration today).
> So, to recap, the goal here is not to make wholesale changes to existing code
> which might use the existing operators, but to provide the "==>" operator for
> scenarios where the operator aids readability or otherwise makes sense.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
