Skip to content

Correct Evaluate-in-Hold test expectation for empty Evaluate[]#27

Merged
stblake merged 1 commit into
mainfrom
fix/evaluate-hold-empty-sibling-test
Jul 22, 2026
Merged

Correct Evaluate-in-Hold test expectation for empty Evaluate[]#27
stblake merged 1 commit into
mainfrom
fix/evaluate-hold-empty-sibling-test

Conversation

@msollami

Copy link
Copy Markdown
Collaborator

Summary

Hold[Evaluate[], 1+1] was asserted to yield Hold[2], but that expectation is incorrect per Wolfram semantics — the evaluator was already right (Hold[1 + 1]). This corrects the sole failing assertion in evaluate_tests.

Changes

  • tests/test_evaluate.c: change the expected value of Hold[Evaluate[], 1+1] from Hold[2] to Hold[1 + 1], with an explanatory comment.

Rationale

An empty Evaluate[] splices away (-> Sequence[]) but does not force its siblings. Evaluate overrides Hold only when it is directly the head of a held slot. This is consistent with the passing non-empty case Hold[Evaluate[1+1], 2+2] -> Hold[2, 2+2]: an empty Evaluate cannot have more reach than a non-empty one. No engine/behavior change — test-only.

Testing

  • evaluate_tests now exits 0 (was aborting on this assertion); confirmed it was the only failing assertion.

Ticket

beads-planning-0c8

Hold[Evaluate[], 1+1] was asserted to yield Hold[2], but an empty
Evaluate[] splices away (-> Sequence[]) without forcing its siblings:
only an Evaluate directly heading a held slot overrides Hold for that
slot. This mirrors the passing non-empty case
Hold[Evaluate[1+1], 2+2] -> Hold[2, 2+2] -- an empty Evaluate cannot
have more reach than a non-empty one. The evaluator already produced
the correct Hold[1 + 1]; only the assertion was wrong. Corrected it.
@stblake
stblake merged commit a9a82a5 into main Jul 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants