-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix Ix laws #119
base: master
Are you sure you want to change the base?
Fix Ix laws #119
Conversation
Changed the tests in Tests.QuickCheck.Classes.Ix to match the laws in the documentation of Data.Ix In particular ixRangeIndex was incorrect: *> import Data.Ix *> x11 = (1,1) :: (Int,Int) *> x33 = (3,3) :: (Int,Int) *> x20 = (2,0) :: (Int,Int) *> x11 <= x33 && (x20 >= x11 && x20 <= x33) True (0.01 secs, 960,736 bytes) *> index (x11, x33) x20 *** Exception: Error in array index *> inRange (x11, x33) x20 False
Let me also present an otherwise lawful
For example let the element type be a digit (number from 0-9), then
This is because the Standard If you are naive like me you might want to 'fix' this by defining
and using the extended bounds
Arguably another class
However this places restrictions on the possible derivation schemes. In what way, number and order may different (field-)types You may consider this a contrived instance and I certainly agree this If you think of adding the aforementioned implicit laws I hope you consider such unusual If you want to allow/support such instances for now, then the precondition Meanwhile I'm thankful that your code helped me uncover that the |
Thoughts:
In |
The test suite hangs forever (several hours before I stopped) when it tests
Hmmm, at first I was surprised you think there is no relationship between
instead of the actual documentation
My wishful interpretation made so much sense to me. The So I basically thought we had And here is another attempt at translating the documentation
into laws such that they are satisfiable by the
The stricter variant (that enforces more intuitive
Though these laws assume a So let's assume the range is not ordered in a meaningful way.
However we do not know whether
we should rather refer to minimal elements. I give up at trying to come up with a law here. I agree the |
Changed the tests in
Tests.QuickCheck.Classes.Ix
to matchthe laws in the documentation of
Data.Ix
In particular
ixRangeIndex
was incorrect:I'm confused by the
do
s in the code. Someone more experienced with QuickCheck than me should check if it is really ok to remove them.I also removed the universal precondition that the lower bound is smaller than the upper bound, as it is not a documented law in
Data.Ix
.While
Ord
is a superclass ofIx
the documented laws do not depend onOrd
. Although the documentation introducesIx
asIn my mind this means that an instance of
Ord
orders the inhabitants of the type in a sequence. An instance ofIx
drops some elements from that sequence (likex20
in the example above) but retains the order of the remaining elements such that it is a subsequence.Hence I think the following law captures the relation between
Ord
andIx
:Further the documentation in
Data.Ix
continuesFrom this I derive the law:
Though I have not added any such implicit law from
Data.Ix
in this commit.