You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As exemplified in #698 and #598, the (Old a, Num a, SymVal a) => Num (SBV a) instance creates lots of type-checking programs that actually do not work in practice.
The instance itself, however, is useful. It takes care of lifting of arithmetic operations over all basic types (Integers, signed/unsigned words, floats etc.); and it works like a charm. But when someone defines their own instance of Num for a custom type T, then they automatically get an Num (SBV T) for that type as well, which doesn't do what they'd have expected it to do. (It errors out in general; but there might be situations it silently does the "wrong" unexpected thing as well.)
-- Abs is problematic for floating point, due to -0; case, so we carefully shuttle it down
-- to the solver to avoid the can of worms. (Alternative would be to do an if-then-else here.)
This might lead to more boiler-plate code in the SBV code base itself, but it might things better in the long run. In particular, as Andreas pointed out, we can have more of "if it type checks it works" behavior that Haskell programmers expect, which is currently not the case for this instance.
The text was updated successfully, but these errors were encountered:
As exemplified in #698 and #598, the
(Old a, Num a, SymVal a) => Num (SBV a)
instance creates lots of type-checking programs that actually do not work in practice.The instance itself, however, is useful. It takes care of lifting of arithmetic operations over all basic types (Integers, signed/unsigned words, floats etc.); and it works like a charm. But when someone defines their own instance of
Num
for a custom typeT
, then they automatically get anNum (SBV T)
for that type as well, which doesn't do what they'd have expected it to do. (It errors out in general; but there might be situations it silently does the "wrong" unexpected thing as well.)We should consider removing the instance:
sbv/Data/SBV/Core/Model.hs
Lines 1322 to 1329 in 720255d
This might lead to more boiler-plate code in the SBV code base itself, but it might things better in the long run. In particular, as Andreas pointed out, we can have more of "if it type checks it works" behavior that Haskell programmers expect, which is currently not the case for this instance.
The text was updated successfully, but these errors were encountered: