rascal
rascal copied to clipboard
Unexpected behavior of anti-pattern (!) as argument of descendant pattern (/)
Describe the bug
Matches of the form /!P := S have unexpected behavior.
To Reproduce
In the REPL:
rascal>/!4 := 3;
bool: true <== as expected
rascal>/!4 := 4;
bool: false <== as expected
rascal>/!4 := [];
bool: true <== reasonable
rascal>/!4 := [4];
bool: true <== strictly correct since 4 does not match [4], but unexpected
rascal>/!4 := [1,2,3,4];
bool: true <== here it becomes clear that /!4 cannot be used
to detect that there is no occurrence of 4 in the subject
The behavior seems to be:
- generate all (sub)values of S (including S itself)
- on the first failing match between P and that subvalue, /!P := S succeeds and gives true.
- only if there are no failing matches, return false.
Expected behavior A more intuitive behavior would be that the argument P is applied to all subvalues of the subject and the match succeeds when no sub value matches P.
Desktop (please complete the following information):
- Context: Eclipse plugin,
- Rascal Version [ 0.19.4-RC6], but this applies to any version I believe.
Additional context
Some Rascal tests related to this in lang::rascal::tests::functionality::PatternDescendant are being ignored, and one test succeeds by sheer coincidence:
test bool descendant7() = /!4 := [1,2,3,2];
and it would also succeed for the subject [1,2,3,4].
We have to decide on the desired behavior of /! before we can implement this in the compiler.
I don't see the problem.
/!4 := [1,2,3,4];means to "do find any term that does not match 4"!/4 := [1,2,3,4];means to "do not find any term that does match 4"
Both are valid queries for different intentions. If we would change the behavior of the special nesting /! to start to mean !/ then I would be confused.
If weimplement the ! and the / independently from each other, with no special cases, then the semantics would remain predictable.