How about we add an == operator:

roel:
(a, b) -> c
where
if a == Foo(_) then
…
else
…
end

There are many other ways to do comparison in Stratego right now, but they all have their limitations.

!a => b // two operators? one of which is a build?
// try explaining that to students who never use build these days…
!a; ?b // same problem.
Foo() := a // not very natural (plus b := a now gives an “already bound” warning in the editor)
(Foo(), a) // doesn’t work with patterns. syntactically noisy.
<Foo(id)> a // srsly?

The only reason why I never added this before is because Stratego already has so many operators. But there really seems to be a good use case here.

Submitted by Lennart Kats on 21 May 2010 at 10:14

Probably a good idea, but

will it do two way matching? Since that is suggested by the use of patterns with variables and the symmetry of the operator

:= should not exclude cases where left-hand side contains bound variables; := is pattern assignment (not variable assignment) and may fail

:= does not exclude does cases, but gives a warning. It is a very common error to write:

roel:
(a, b) -> c
where
a := ;
c := (a, …)

Where the programmer attempts to use a as a fresh variable.

Symmetry is indeed a problem. A truely symmetric == would translate both Foo(_) == a and a == Foo(_) to !a => Foo(_). Equality testing without holes/wildcards on either side can also be naturally handled symettrically, e.g. Bar() == Bar(). So far so good.

It only gets a bit problematic once you have terms without wildcards on both sides: consider Bar(){1} == Bar() or Bar(){c} == Bar() for some bound c. One thing you could do there is do two consecutive equality tests to ensure symmetry and/or give a warning/error. Not sure what would be the best way to treat this corner case. Alternatively an assymetric equality operator could be added, but really the overloading of := causes too many problems. Stratego code tends to be brittle enough as is.

I think there should be a where around the generated check, so the equality operator cannot be (inadvertently) abused to also change the current term.

Isn’t there an implicit wildcard for the annotations on the right term in your example Bar(){1} == Bar()?

@Danny:

Good point about the where.

There is an implicit wildcard. But it’s not like a regular wild card since the same term can be used in a build: !Bar(){1} => Bar() succeeds while !Bar() => Bar(){1} fails… This makes symmetry difficult when considering annotations. On second thought I’m actually not sure if you can catch these cases as I suggested earlier … so maybe we’d really need an asymmetric equality operator…