assert.equal erroneously assumes partially applied terms to be LC numerals

[Voileexperiments]

repro:

f = \ z _. z

import { assert, LC, getSolution } from "./lc-test.js";

LC.configure({ purity: "Let", numEncoding: "Church", verbosity: "Concise" });
const { f } = LC.compile(getSolution());

describe("Multiply", () => {
  it("example tests", () => {
    assert.equal( f("test"), "test" );
  });
});

This gives

toInt: function result(arg) {
      let argEnv;
      if ( arg?.term && arg?.env ) ({ term: arg, env: argEnv } = arg); // if callback is passed another callback, or a term
      const termVal = new Tuple( typeof arg === 'number' ? fromInt(arg) : arg , new Env(argEnv) );
      if ( term.name==="_" )
        return runEval( new Tuple(term.body, new Env(env)), stack );
      else
        return runEval( new Tuple(term.body, new Env(env).setThunk(term.name, termVal)), stack );
    } is not a number in numEncoding Church

Another reason to not automatically assume LC terms to be integers and convert them.

Also, isn't assert.equal supposed to keep the arguments intact?

[JohanWiltink]

This was a design decision.

[Kacarott]

Also, isn't assert.equal supposed to keep the arguments intact?

assert.equal isn't anything we wrote, but it seems to automatically call .valueOf on any objects.

We initially added the .valueOf to the LC terms (for implicit conversion) to make things like testing "easier" by being able to use assert.equal, however we since then added assert.numEql. Off the top of my head, I don't think we need the .valueOf property any more, and there is merit to removing implicit behaviour where it isn't an advantage. However I suspect that removing it may break things (??) I'd have to look closer.