Wouldn't it make sense to have two different types for naturals, one with exception and one with saturating semantics? I can imagine cases where one would prefer one over the other and none of them seem simple enough to simulate if only the other one is given.
On 14 Nov 2014, at 07:05, Herbert Valerio Riedel
On 2014-11-13 at 23:20:47 +0100, Mario Blažević wrote: [...]
Regarding the partial vs. saturated negation, I'm in favour of the former. However, there is another option nobody mentioned so far: NaN. I.e.,
1 - 2 = NaN 3 + 1 - 2 = 2 3 + (1 - 2) = NaN
Could a GMP-based implementation provide such semantics without too much performance loss? If so, this would be my preference.
Purely from a technical point of view:
If you look at how it's implemented right now:
https://phabricator.haskell.org/D473
being able to represent a 'not-a-natural' would be possible for the GMP2-backed 'Natural' by adding a 'NatErr#' constructor, i.e.
data Natural = NatS# Word# | NatJ# {-# UNPACK #-} !BigNat | NatErr# deriving (Eq,Ord)
that, however, would require to add one or two case-distinction to all 'Natural' operations, and we probably shouldn't auto-derive 'Eq'/'Ord' anymore (as it's no longer to be considered a properly ordered set/equivalence relation with that absorbing NatErr# element)
However, also the fallback implementation (for when GHC is configured with a the old integer-gmp or the integer-simple backend) which is
newtype Natural = Natural Integer
would need to become more complex, as the lightweight newtype would be turned into something like
data Natural = Natural !Integer | NaturalErr
So I'm afraid handling not-a-natural would indeed come at a cost.
Cheers, hvr _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries