So that raises a new issue—
Is there a good reason to keep the current system? (I think it’s technically unspecified behavior, not undefined behavior; the spec says the predicate always needs to return some value, but doesn’t specify what that value should be.) In general, asking Dialog to compute something it can’t represent just makes the predicate fail; as far as I know, multiplication is the one place where it returns an incorrect result instead.
On Å-machine, this behavior is in fact specified: the MUL_NUM instruction returns (A × B) & $3FFF. But I’m struggling to think of cases where this behavior would be desirable, beyond using the overflow to implement a hash function or PRNG.
Would it be better to change the behavior going forward, and have ($ times $ into $) fail on overflow, just like ($ plus $ into $) or ($ minus $ into $) do? This is especially relevant now as we figure out what the 32-bit behavior should be.
- Overflow should make the predicate fail
- Overflow should return an incorrect value
- I don’t care