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
Currently, at the level of our core lattices (IntLattice, StringLattice, …), failures (such as dividing by zero, sqrt’ing a negative number, etc.) are not dealt with. It the best case, they are ignored (e.g., when the index in stringRef is actually out of range); in the worst case, they can lead to Scala NaNs (dangerous!) or Scala exceptions.
We can use the existing MayFail monad to include such potential errors as the result of an operation in these core lattices (as is already done at higher levels in SchemeLattice and in the implementation of Scheme primitives).
The text was updated successfully, but these errors were encountered:
Similar to how failures are dealt with in the primitives, it might be better to employ monadic abstraction here (i.e., using the MonadError interface) instead of returning a MayFail for every operation. This would enable more flexibility in choosing how errors are dealt with in core lattice operations (e.g., a particular monad can then still choose to ignore failures), and bridge the gap between the implementation of the primitives and the lattice operations.
Currently, at the level of our core lattices (
IntLattice
,StringLattice
, …), failures (such as dividing by zero, sqrt’ing a negative number, etc.) are not dealt with. It the best case, they are ignored (e.g., when the index instringRef
is actually out of range); in the worst case, they can lead to Scala NaNs (dangerous!) or Scala exceptions.We can use the existingMayFail
monad to include such potential errors as the result of an operation in these core lattices (as is already done at higher levels inSchemeLattice
and in the implementation of Scheme primitives).The text was updated successfully, but these errors were encountered: