rascal icon indicating copy to clipboard operation
rascal copied to clipboard

Unexpected behavior of anti-pattern (!) as argument of descendant pattern (/)

Open PaulKlint opened this issue 4 years ago • 1 comments

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.

PaulKlint avatar Sep 18 '21 18:09 PaulKlint

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.

jurgenvinju avatar Sep 20 '21 08:09 jurgenvinju