Inconsistent parsing and/or evaluation for negative `u64`.
Closed this issue · 1 comments
Something is wrong with the reading and subsequent handling of negative (Lurk) u64s.
A naked read yields a result obviously larger than u64. This result appears to just be the corresponding Num (see example below).
However, attempting to perform a computation on the expression yields an error — whereas using the corresponding Num does not.
I suspect we are creating an illegal value — perhaps tagged as u64 but with a value out of range for that type.
Most importantly, this behavior should be consistent. Intuitively, although a bit weird, -1u64 should probably just be syntax for 0xFFFFFFFFFFFFFFFF. That would be the most useful result. Alternately, we might decide this should be a parsing error.
Whatever we do, the current state is a bug.
commit: 2024-02-13 1d4d308e2bc12f5ab431ea210c0b722f9eb31825
Lurk REPL welcomes you.
user> -1u64
[1 iteration] => 0x30644e72e131a029b85045b68181585d2833e84879b9709143e1f593f0000000
user> -1
[1 iteration] => 0x30644e72e131a029b85045b68181585d2833e84879b9709143e1f593f0000000
user> (- 0u64 1u64)
[3 iterations] => 18446744073709551615u64
user> (+ (- 0u64 1u64) 10u64)
[6 iterations] => 9u64
user> (+ -1u64 10u64)
Error: Evaluation encountered an error after 2 iterations
user> (+ -1 10u64)
[3 iterations] => 9
Closed by #1171