Have assertEqual support alpha equivalence

[ngeiswei]

Describe the bug
Probably not a bug, but it would be very convenient if assertEqual and assertEqualToResult could support alpha-equivalence. Either it could be the default (maybe undesirable though), or new assert operators, such as assertAlphaEqual and assertAlphaEqualToResult could be added.

To Reproduce
Steps to reproduce the behavior:

1. Run the following MeTTa script

(= (foo) (R $x $y))
!(assertEqual (foo) (R $x $y))

2. See output

Expected behavior
If assertEqual supported alpha-equivalence it would output [()].

Actual behavior
Instead it outputs

[(Error (assertEqual (foo) (R $x $y)) 
Expected: [(R $x $y)]
Got: [(R $x#31 $y#32)]
Missed result: (R $x $y))]

Additional context

• MeTTa version: 0.2.0+ga57bb5b2.d20240718
• I suppose it's better to add assertAlphaEqual and assertAlphaEqualToResult than relaxing the behavior of assertEqual. Such addition could be at the Rust level or at the MeTTa level. Note that I have already implemented an alpha-equivalence MeTTa function here https://github.com/ngeiswei/chaining/blob/97923a18f3c6138f2eaf697e89ca9500e219e729/experimental/converters/calculi-converter.metta#L311-L327. However it is slow and I wonder if it would be actually easier to implement at the Rust level. If you think implementing it at the MeTTa level is fine, I'm happy to take care of it.

[vsbogd]

We have a Rust function which checks two atoms for being alpha-equivalent:

hyperon-experimental/lib/src/atom/matcher.rs

Line 1253 in 9c126b1

pub fn atoms_are_equivalent(left: &Atom, right: &Atom) -> bool {

Thus it is not a problem to add couple new operations actually.

[ngeiswei]

Awesome, would you do it? Or would you rather have me do it? I'll be a bit slower but it should be within my reach.

[ngeiswei]

Also, there are at least two ways to do it:

1. Expose atoms_are_equivalent to MeTTa, then implement assertAlphaEqual in MeTTa (add it in stdlib.metta I suppose).
2. Implement assertAlphaEqual in Rust, exposed to MeTTa.

Even if we go with 2, I think it would be useful to expose atoms_are_equivalent to MeTTa. I did find it useful in my own code, and I assume the Rust implementation is far more efficient than my MeTTa implementation.

[ngeiswei]

Also, how would you name in MeTTa

• atoms_are_equivalent. I have used =alpha in my code for instance.
• assertEqual up to alpha-equivalence? I had thought of assertAlphaEqual but they are other possibilities like assertEquivalent, etc.

[ngeiswei]

Also, a different issue that I'm bringing only because we are discussing names. I don't understand the name assertEqualToResult. Didn't you mean assertEqualToResults, ending with an s? But anyway, that certainly is for another issue.

[vsbogd]

As @DaddyWesker started working on it I am adding my thought on it.

I think adding =alfa function into stdlib (which is call to

hyperon-experimental/lib/src/atom/matcher.rs

Line 1253 in 9c126b1

pub fn atoms_are_equivalent(left: &Atom, right: &Atom) -> bool {

) is useful.

I would vote for reimplementing assertEqual using =alfa in pure MeTTa and don't introduce special assertAlfaEqual, but I would also check it with @Necr0x0Der. I would also use atoms_are_equivalent inside assertEqualToResult if we agree on changing assertEqual.

I believe name of the assertEqualToResult is not quite important. Result of the atom evaluation can contain many atoms. We can say it is a single result or many results. It is some language ambiguity. Thus I don't see reasons to prefer results over result and as assertEqualToResult is already widely used I would keep it as is.

[ngeiswei]

After more thoughts, I think it is better to have assertEqual support non-alpha equivalence by default, and add an extra assertAlphaEqual for alpha equivalence, because equality with alpha equivalence is strictly more permissive than equality without alpha equivalence. And in the context of unit tests I think you want the default to be as restrictive as possibly to capture more errors.

[ngeiswei]

I want to add that I have many unit tests that are purposely testing equality without alpha equivalence.

[vsbogd]

equality with alpha equivalence is strictly more permissive than equality without alpha equivalence. And in the context of unit tests I think you want the default to be as restrictive as possibly to capture more errors.

In general I agree. But in practice there are many situations when user's expectation of names are more or less arbitrary and interpreter can choose another naming (see #127 (comment) for example). Anyway I don't object adding separate alpha equivalent assert.

[ngeiswei]

That makes sense too, let's see what @Necr0x0Der has to say.