From conal at conal.net Sun Dec 2 12:27:06 2007 From: conal at conal.net (Conal Elliott) Date: Sun Dec 2 12:22:46 2007 Subject: Proposal: add "writer" Monad instance (,) o (Ticket #1951) Message-ID: I'd like to have a (,)-style writer instance alongside the (->)-based reader instance for Monad in Control.Monad.Instances. Here's the current reader: instance Monad ((->) r) where return = const f >>= k = \ r -> k (f r) r and my proposed writer: instance Monoid o => Monad ((,) o) where return = pure (o,a) >>= f = (o `mappend` o', a') where (o',a') = f a where the return definition relies on the Applicative instance of ((,) o). Written out explicitly, return a = (mempty,a) Control.Monad.Instances will also need two new imports: import Data.Monoid (Monoid(..)) import Control.Applicative (pure) Suggested review period: two weeks (ending Dec 16). Comments? - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20071202/abee7096/attachment.htm From conal at conal.net Sun Dec 2 12:39:51 2007 From: conal at conal.net (Conal Elliott) Date: Sun Dec 2 12:35:31 2007 Subject: Bounded and floating types Message-ID: Currently Float & Double do not have standard Bounded instances. Is there any reason not to use the following? instance Bounded Float where { minBound = -1/0; maxBound = 1/0 } instance Bounded Double where { minBound = -1/0; maxBound = 1/0 } If I don't hear objections, I'll submit a ticket and re-send a proposal note. - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20071202/83610be4/attachment.htm From conal at conal.net Sun Dec 2 12:57:50 2007 From: conal at conal.net (Conal Elliott) Date: Sun Dec 2 12:53:34 2007 Subject: Proposal: Max and Min for Monoid (ticket # 1952) Message-ID: I'd like to add two instances to Data.Monoid, alongside of All/Any, Sum/Product, and First/Last. Here's a current instance (as a style example): -- | Boolean monoid under conjunction. newtype All = All { getAll :: Bool } deriving (Eq, Ord, Read, Show, Bounded) instance Monoid All where mempty = All True All x `mappend` All y = All (x && y) My proposed addition: -- | Ordered monoid under 'max'. newtype Max a = Max { getMax :: a } deriving (Eq, Ord, Read, Show, Bounded) instance (Ord a, Bounded a) => Monoid (Max a) where mempty = Max minBound Max a `mappend` Max b = Max (a `max` b) -- | Ordered monoid under 'min'. newtype Min a = Min { getMin :: a } deriving (Eq, Ord, Read, Show, Bounded) instance (Ord a, Bounded a) => Monoid (Min a) where mempty = Min minBound Min a `mappend` Min b = Min (a `min` b) I have a niggling uncertainty about the Ord & Bounded instances for Min a? Is there a reason flip the a ordering instead of preserving it? Suggested review period: two weeks (ending December 16). Comments? - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20071202/c9b2f9d5/attachment.htm From conal at conal.net Sun Dec 2 13:18:57 2007 From: conal at conal.net (Conal Elliott) Date: Sun Dec 2 13:14:38 2007 Subject: Bounded and floating types In-Reply-To: References: Message-ID: Oops -- I'd incorrectly assumed that Haskell guarantees Float & Double to have infinities. Thanks, - Conal On Dec 2, 2007 9:50 AM, Lennart Augustsson wrote: > But that only makes sense for floating point types that have -Infinity and > +Infinity. > > On Dec 2, 2007 5:39 PM, Conal Elliott wrote: > > > Currently Float & Double do not have standard Bounded instances. Is > > there any reason not to use the following? > > > > instance Bounded Float where { minBound = -1/0; maxBound = 1/0 } > > instance Bounded Double where { minBound = -1/0; maxBound = 1/0 } > > > > If I don't hear objections, I'll submit a ticket and re-send a proposal > > note. > > > > - Conal > > > > > > _______________________________________________ > > Libraries mailing list > > Libraries@haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20071202/c9a3334d/attachment.htm From isaacdupree at charter.net Sun Dec 2 13:21:10 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Sun Dec 2 13:17:55 2007 Subject: Bounded and floating types In-Reply-To: References: Message-ID: <4752F796.1080209@charter.net> Conal Elliott wrote: > Currently Float & Double do not have standard Bounded instances. Is there > any reason not to use the following? > > instance Bounded Float where { minBound = -1/0; maxBound = 1/0 } > instance Bounded Double where { minBound = -1/0; maxBound = 1/0 } by the way, that minBound definition is (negate(1/0)), not ((negate 1) / 0) ... although that probably doesn't make a difference Isaac From igloo at earth.li Sun Dec 2 14:26:05 2007 From: igloo at earth.li (Ian Lynagh) Date: Sun Dec 2 14:21:43 2007 Subject: Proposal: Max and Min for Monoid (ticket # 1952) In-Reply-To: References: Message-ID: <20071202192605.GA11882@matrix.chaos.earth.li> On Sun, Dec 02, 2007 at 09:57:50AM -0800, Conal Elliott wrote: > > instance (Ord a, Bounded a) => Monoid (Min a) where > mempty = Min minBound I think you mean: mempty = Min maxBound > Min a `mappend` Min b = Min (a `min` b) Thanks Ian From conal at conal.net Sun Dec 2 15:04:49 2007 From: conal at conal.net (Conal Elliott) Date: Sun Dec 2 15:07:03 2007 Subject: Proposal: Max and Min for Monoid (ticket # 1952) In-Reply-To: <20071202192605.GA11882@matrix.chaos.earth.li> References: <20071202192605.GA11882@matrix.chaos.earth.li> Message-ID: oops! copy/paste/edit error. thanks for catching. On Dec 2, 2007 11:26 AM, Ian Lynagh wrote: > On Sun, Dec 02, 2007 at 09:57:50AM -0800, Conal Elliott wrote: > > > > instance (Ord a, Bounded a) => Monoid (Min a) where > > mempty = Min minBound > > I think you mean: > > mempty = Min maxBound > > > Min a `mappend` Min b = Min (a `min` b) > > > Thanks > Ian > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20071202/d046b176/attachment-0001.htm From lemming at henning-thielemann.de Sun Dec 2 16:08:30 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun Dec 2 16:04:09 2007 Subject: Bounded and floating types In-Reply-To: References: Message-ID: On Sun, 2 Dec 2007, Conal Elliott wrote: > Oops -- I'd incorrectly assumed that Haskell guarantees Float & Double to > have infinities. Thanks, - Conal Aside from that - what do you intend to do with the bounds? From ross at soi.city.ac.uk Sun Dec 2 18:25:54 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sun Dec 2 18:22:03 2007 Subject: Proposal: Max and Min for Monoid (ticket # 1952) In-Reply-To: References: Message-ID: <20071202232554.GA20705@soi.city.ac.uk> On Sun, Dec 02, 2007 at 09:57:50AM -0800, Conal Elliott wrote: > My proposed addition: > > -- | Ordered monoid under 'max'. > newtype Max a = Max { getMax :: a } > deriving (Eq, Ord, Read, Show, Bounded) > > instance (Ord a, Bounded a) => Monoid (Max a) where > mempty = Max minBound > Max a `mappend` Max b = Max (a `max` b) Funny, I was thinking of proposing a Max type that adjoined a synthetic identity, as we did in the finger tree paper: data Max a = NoMax | Max a deriving (Eq, Ord, Read, Show) instance Ord a => Monoid (Max a) where mempty = NoMax NoMax `mappend` b = b a `mappend` NoMax = a Max x `mappend` Max y = Max (x `max` y) and similarly for Min. One could even define getMax :: Bounded a => Max a -> a getMax NoMax = minBound getMax (Max x) = x From dbenbenn at gmail.com Sun Dec 2 18:45:40 2007 From: dbenbenn at gmail.com (David Benbennick) Date: Sun Dec 2 18:41:19 2007 Subject: Proposal: Bounded instance for IntSet (ticket #1953) Message-ID: >From http://hackage.haskell.org/trac/ghc/ticket/1953 : I propose to add a Bounded instance to IntSet.hs. IntSet is in Ord, and there are only finitely many instances of IntSet. Therefore there is a min IntSet and a max IntSet. It turns out these bounds are very simple: instance Bounded IntSet where minBound = empty maxBound = singleton maxBound Suggested deadline: December 16, 2007. From ross at soi.city.ac.uk Sun Dec 2 18:53:36 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sun Dec 2 18:49:15 2007 Subject: Proposal: Bounded instance for IntSet (ticket #1953) In-Reply-To: References: Message-ID: <20071202235336.GA20802@soi.city.ac.uk> On Sun, Dec 02, 2007 at 03:45:40PM -0800, David Benbennick wrote: > I propose to add a Bounded instance to IntSet.hs. > > IntSet is in Ord, and there are only finitely many instances of > IntSet. Therefore there is a min IntSet and a max IntSet. It turns out > these bounds are very simple: > > instance Bounded IntSet where > minBound = empty > maxBound = singleton maxBound These are the minimum and maximum under the Ord instance (also for Set), but what is the intuition behind that ordering? From dbenbenn at gmail.com Sun Dec 2 19:01:05 2007 From: dbenbenn at gmail.com (David Benbennick) Date: Sun Dec 2 18:56:44 2007 Subject: Proposal: Bounded instance for IntSet (ticket #1953) In-Reply-To: <20071202235336.GA20802@soi.city.ac.uk> References: <20071202235336.GA20802@soi.city.ac.uk> Message-ID: On 12/2/07, Ross Paterson wrote: > These are the minimum and maximum under the Ord instance (also for Set), > but what is the intuition behind that ordering? The order on IntSet is the well-known lexicographic order (see http://en.wikipedia.org/wiki/Lexicographical_order). If this proposal is accepted, I intend to propose the Bounded instance for Set next (Bounded a => Bounded (Set a)). From ross at soi.city.ac.uk Sun Dec 2 19:13:37 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sun Dec 2 19:09:16 2007 Subject: Proposal: Bounded instance for IntSet (ticket #1953) In-Reply-To: References: <20071202235336.GA20802@soi.city.ac.uk> Message-ID: <20071203001337.GA20896@soi.city.ac.uk> On Sun, Dec 02, 2007 at 04:01:05PM -0800, David Benbennick wrote: > On 12/2/07, Ross Paterson wrote: > > These are the minimum and maximum under the Ord instance (also for Set), > > but what is the intuition behind that ordering? > > The order on IntSet is the well-known lexicographic order (see > http://en.wikipedia.org/wiki/Lexicographical_order). Yes, but when does one use that ordering on sets? From stefanor at cox.net Sun Dec 2 19:23:11 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Sun Dec 2 19:18:53 2007 Subject: Proposal: Bounded instance for IntSet (ticket #1953) In-Reply-To: References: <20071202235336.GA20802@soi.city.ac.uk> Message-ID: <20071203002311.GA3719@localhost.localdomain> On Sun, Dec 02, 2007 at 04:01:05PM -0800, David Benbennick wrote: > On 12/2/07, Ross Paterson wrote: > > These are the minimum and maximum under the Ord instance (also for Set), > > but what is the intuition behind that ordering? > > The order on IntSet is the well-known lexicographic order (see > http://en.wikipedia.org/wiki/Lexicographical_order). If this proposal > is accepted, I intend to propose the Bounded instance for Set next > (Bounded a => Bounded (Set a)). This contradicts your code, for the maximal element in the lexicographic order is *not* singleton maxBound, but rather fromList [minBound .. maxBound]. (The libraries agree with your code but not your explanation...) Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/libraries/attachments/20071202/6df2bdf8/attachment.bin From igloo at earth.li Sun Dec 2 19:29:45 2007 From: igloo at earth.li (Ian Lynagh) Date: Sun Dec 2 19:25:23 2007 Subject: Proposal: Bounded instance for IntSet (ticket #1953) In-Reply-To: <20071203002311.GA3719@localhost.localdomain> References: <20071202235336.GA20802@soi.city.ac.uk> <20071203002311.GA3719@localhost.localdomain> Message-ID: <20071203002945.GA28719@matrix.chaos.earth.li> On Sun, Dec 02, 2007 at 04:23:11PM -0800, Stefan O'Rear wrote: > On Sun, Dec 02, 2007 at 04:01:05PM -0800, David Benbennick wrote: > > On 12/2/07, Ross Paterson wrote: > > > These are the minimum and maximum under the Ord instance (also for Set), > > > but what is the intuition behind that ordering? > > > > The order on IntSet is the well-known lexicographic order (see > > http://en.wikipedia.org/wiki/Lexicographical_order). If this proposal > > is accepted, I intend to propose the Bounded instance for Set next > > (Bounded a => Bounded (Set a)). > > This contradicts your code, for the maximal element in the lexicographic > order is *not* singleton maxBound, but rather fromList [minBound .. > maxBound]. I think he means lexicographic order of toAscList set. I agree that lexicographic order of toDescList makes more intuitive sense to me, though. Thanks Ian From john at repetae.net Sun Dec 2 19:37:23 2007 From: john at repetae.net (John Meacham) Date: Sun Dec 2 19:33:02 2007 Subject: Proposal: Bounded instance for IntSet (ticket #1953) In-Reply-To: References: Message-ID: <20071203003723.GA30047@momenergy.repetae.net> On Sun, Dec 02, 2007 at 03:45:40PM -0800, David Benbennick wrote: > >From http://hackage.haskell.org/trac/ghc/ticket/1953 : > > I propose to add a Bounded instance to IntSet.hs. > > IntSet is in Ord, and there are only finitely many instances of > IntSet. Therefore there is a min IntSet and a max IntSet. It turns out > these bounds are very simple: > > instance Bounded IntSet where > minBound = empty > maxBound = singleton maxBound This seems fairly unintuitive me. the natural choices of minimum and maximum bounds for a set would seem to be singleton minBound vs singleton maxBound or empty vs universal (fromList [minBound .. maxBound]) set the odd combination of the two proposed just feels off to me. John -- John Meacham - ?repetae.net?john? From dbenbenn at gmail.com Sun Dec 2 20:56:18 2007 From: dbenbenn at gmail.com (David Benbennick) Date: Sun Dec 2 20:51:56 2007 Subject: Proposal: Bounded instance for IntSet (ticket #1953) In-Reply-To: <20071203003723.GA30047@momenergy.repetae.net> References: <20071203003723.GA30047@momenergy.repetae.net> Message-ID: On 12/2/07, Ross Paterson wrote: > Yes, but when does one use that ordering on sets? IntSet uses that ordering. On 12/2/07, John Meacham wrote: > This seems fairly unintuitive me. the natural choices of minimum and > maximum bounds for a set would seem to be > > singleton minBound vs singleton maxBound > > or > > empty vs universal (fromList [minBound .. maxBound]) set > > the odd combination of the two proposed just feels off to me. There is no choice. Given the existing ordering on IntSets, there is a unique smallest element, and a unique largest element. There is a legitimate discussion to be had about what ordering to use on IntSets, but that discussion is not relevant to this proposal. No matter what ordering you pick, IntSet will be bounded, so should be in class Bounded. To repeat: *** This proposal is not about changing the ordering of IntSets. It is only about adding the Bounded instance that is determined by the existing ordering. *** From dbenbenn at gmail.com Sun Dec 2 23:56:38 2007 From: dbenbenn at gmail.com (David Benbennick) Date: Sun Dec 2 23:52:19 2007 Subject: QuickCheck properties for IntSet Message-ID: Here's a patch to IntSet.hs that adds many QuickCheck properties. It adds properties testing almost all of the public interface of IntSet, and also properties testing that the data type invariants are never broken. (The patch doesn't test the Data, Eq, Monoid, Read, or Typeable instances.) Also, this patch removes a helper function, foldlStrict, and replaces it with calls to Data.List.foldl'. I have two questions: 1) Is this the right way to submit patches? 2) Is there a good reason that IntSet doesn't use "deriving Eq", and instead manually implements the Eq instance? -------------- next part -------------- New patches: [IntSet QuickCheck properties David Benbennick **20071203040728 1) Remove foldlStrict, and use Data.List.foldl' instead. 2) Add many QuickCheck properties, checking almost every exported function of IntSet. ] { hunk ./Data/IntSet.hs 114 -import List (nub,sort) -import qualified List hunk ./Data/IntSet.hs 115 +import qualified Prelude hunk ./Data/IntSet.hs 315 - = foldlStrict union empty xs + = List.foldl' union empty xs hunk ./Data/IntSet.hs 410 +-- Return LT if t1 is a proper subset of t2, +-- EQ if t1 == t2, and GT otherwise. hunk ./Data/IntSet.hs 677 - = foldlStrict ins empty xs + = List.foldl' ins empty xs hunk ./Data/IntSet.hs 942 -{-------------------------------------------------------------------- - Utilities ---------------------------------------------------------------------} -foldlStrict f z xs - = case xs of - [] -> z - (x:xx) -> let z' = f z x in seq z' (foldlStrict f z' xx) - - hunk ./Data/IntSet.hs 943 -{-------------------------------------------------------------------- - Testing ---------------------------------------------------------------------} -testTree :: [Int] -> IntSet -testTree xs = fromList xs -test1 = testTree [1..20] -test2 = testTree [30,29..10] -test3 = testTree [1,4,6,89,2323,53,43,234,5,79,12,9,24,9,8,423,8,42,4,8,9,3] - hunk ./Data/IntSet.hs 961 - arbitrary = do{ xs <- arbitrary - ; return (fromList xs) - } + arbitrary = arbitrary >>= return . fromList + coarbitrary Nil = variant 0 + coarbitrary (Tip x) = variant 1 . coarbitrary x + coarbitrary (Bin _ _ left right) = variant 2 . coarbitrary left . coarbitrary right hunk ./Data/IntSet.hs 997 - == List.sort ((List.\\) (nub xs) (nub ys)) + == List.sort ((List.\\) (List.nub xs) (List.nub ys)) hunk ./Data/IntSet.hs 1002 - == List.sort (nub ((List.intersect) (xs) (ys))) + == List.sort (List.nub ((List.intersect) (xs) (ys))) hunk ./Data/IntSet.hs 1014 - = (sort (nub xs) == toAscList (fromList xs)) + = (List.sort (List.nub xs) == toAscList (fromList xs)) hunk ./Data/IntSet.hs 1017 - Bin invariants + Check that after every operation, an IntSet satisfies its invariants hunk ./Data/IntSet.hs 1019 -powersOf2 :: IntSet -powersOf2 = fromList [2^i | i <- [0..63]] +isValid Nil = True +isValid s = isValid' s where + isValid' (Tip _) = True + isValid' Nil = False + isValid' s@(Bin prefix msk left right) = checkPrefix s && isPow2 msk && checkLeftRight s && isValid' left && isValid' right hunk ./Data/IntSet.hs 1025 --- Check the invariant that the mask is a power of 2. -prop_MaskPow2 :: IntSet -> Bool -prop_MaskPow2 (Bin _ msk left right) = member msk powersOf2 && prop_MaskPow2 left && prop_MaskPow2 right -prop_MaskPow2 _ = True + -- Check that the prefix satisfies its invariant. + checkPrefix s@(Bin prefix msk _ _) = all (\elem -> match elem prefix msk) $ toList s hunk ./Data/IntSet.hs 1028 --- Check that the prefix satisfies its invariant. -prop_Prefix :: IntSet -> Bool -prop_Prefix s@(Bin prefix msk left right) = all (\elem -> match elem prefix msk) (toList s) && prop_Prefix left && prop_Prefix right -prop_Prefix _ = True + isPow2 x = x .&. (x - 1) == 0 hunk ./Data/IntSet.hs 1030 --- Check that the left elements don't have the mask bit set, and the right --- ones do. -prop_LeftRight :: IntSet -> Bool -prop_LeftRight (Bin _ msk left right) = and [x .&. msk == 0 | x <- toList left] && and [x .&. msk == msk | x <- toList right] -prop_LeftRight _ = True + -- Check that the left elements don't have the mask bit set, and the right + -- ones do. + checkLeftRight (Bin _ msk left right) = and [x .&. msk == 0 | x <- toList left] && and [x .&. msk == msk | x <- toList right] + +prop_valid_bkbk a b = isValid $ a \\ b +prop_valid_empty = isValid empty +prop_valid_singleton a = isValid $ singleton a +prop_valid_insert a b = isValid $ insert a b +prop_valid_delete a b = isValid $ delete a b +prop_valid_union a b = isValid $ union a b +prop_valid_unions a = isValid $ unions a +prop_valid_difference a b = isValid $ difference a b +prop_valid_intersection a b = isValid $ intersection a b +prop_valid_filter a b = isValid $ filter a b +prop_valid_partition a b = all isValid [x, y] where + (x, y) = partition a b +prop_valid_split a b = all isValid [x, y] where + (x, y) = split a b +prop_valid_splitMember a b = all isValid [x, y] where + (x, _, y) = splitMember a b +prop_valid_deleteMin a = not (null a) ==> isValid (deleteMin a) +prop_valid_deleteMax a = not (null a) ==> isValid (deleteMax a) +prop_valid_deleteFindMin a = not (null a) ==> isValid (snd $ deleteFindMin a) +prop_valid_deleteFindMax a = not (null a) ==> isValid (snd $ deleteFindMax a) +prop_valid_maxView a = all (isValid . snd) $ maxView a +prop_valid_minView a = all (isValid . snd) $ minView a +prop_valid_map a b = isValid $ map a b +prop_valid_fromList a = isValid $ fromList a +prop_valid_fromAscList a = isValid $ fromAscList b where + b = List.sort a +prop_valid_fromDistinctAscList a = isValid $ fromDistinctAscList b where + b = toList a hunk ./Data/IntSet.hs 1064 - IntSet operations are like Set operations + IntSet functions are like Set functions hunk ./Data/IntSet.hs 1066 +-- Helper hunk ./Data/IntSet.hs 1070 --- Check that IntSet.isProperSubsetOf is the same as Set.isProperSubsetOf. +-- Check the helper is right +prop_toSet :: IntSet -> Bool +prop_toSet a = a == fromList (Set.toList $ toSet a) + +prop_bkbk :: IntSet -> IntSet -> Bool +prop_bkbk a b = toSet (a \\ b) == (toSet a) Set.\\ (toSet b) + +prop_null :: IntSet -> Bool +prop_null a = null a == Set.null (toSet a) + +prop_size :: IntSet -> Bool +prop_size a = size a == Set.size (toSet a) + +prop_member :: Int -> IntSet -> Bool +prop_member a b = member a b == Set.member a (toSet b) + +prop_notMember :: Int -> IntSet -> Bool +prop_notMember a b = notMember a b == Set.notMember a (toSet b) + +-- For testing isSubsetOf and isProperSubsetOf: +-- Given two random sets a and b, it is very unlikely that a is a subset of b. +-- So prop_isSubsetOf only checks the "False" case. +-- prop_isSubsetOf2 manufactures the "True" case. +prop_isSubsetOf :: IntSet -> IntSet -> Bool +prop_isSubsetOf a b = isSubsetOf a b == Set.isSubsetOf (toSet a) (toSet b) + +prop_isSubsetOf2 :: IntSet -> IntSet -> Bool +prop_isSubsetOf2 a b = isSubsetOf a c == Set.isSubsetOf (toSet a) (toSet c) where + c = union a b + hunk ./Data/IntSet.hs 1103 --- In the above test, isProperSubsetOf almost always returns False (since a --- random set is almost never a subset of another random set). So this second --- test checks the True case. hunk ./Data/IntSet.hs 1106 + +prop_empty :: Bool +prop_empty = toSet empty == Set.empty + +prop_singleton :: Int -> Bool +prop_singleton a = toSet (singleton a) == Set.singleton a + +prop_insert :: Int -> IntSet -> Bool +prop_insert a b = toSet (insert a b) == Set.insert a (toSet b) + +prop_delete :: Int -> IntSet -> Bool +prop_delete a b = toSet (delete a b) == Set.delete a (toSet b) + +prop_union :: IntSet -> IntSet -> Bool +prop_union a b = toSet (union a b) == Set.union (toSet a) (toSet b) + +prop_unions :: [IntSet] -> Bool +prop_unions a = toSet (unions a) == Set.unions (Prelude.map toSet a) + +prop_difference :: IntSet -> IntSet -> Bool +prop_difference a b = toSet (difference a b) == Set.difference (toSet a) (toSet b) + +prop_intersection :: IntSet -> IntSet -> Bool +prop_intersection a b = toSet (intersection a b) == Set.intersection (toSet a) (toSet b) + +instance Show (Int -> Bool) where + show _ = " Bool>" +instance Show (Int -> Int) where + show _ = " Int>" +instance Show (Int -> Int -> Int) where + show _ = " Int -> Int>" +instance Arbitrary Char where + arbitrary = choose ('\0', '\255') + +prop_filter :: (Int -> Bool) -> IntSet -> Bool +prop_filter a b = toSet c == Set.filter a (toSet b) where + c = filter a b + +prop_partition :: (Int -> Bool) -> IntSet -> Bool +prop_partition a b = (toSet c, toSet d) == Set.partition a (toSet b) where + (c, d) = partition a b + +prop_split :: Int -> IntSet -> Bool +prop_split a b = (toSet x, toSet z) == Set.split a (toSet b) where + (x, z) = split a b + +prop_splitMember :: Int -> IntSet -> Bool +prop_splitMember a b = (toSet x, y, toSet z) == Set.splitMember a (toSet b) where + (x, y, z) = splitMember a b + +prop_findMin :: IntSet -> Property +prop_findMin a = not (null a) ==> findMin a == Set.findMin (toSet a) + +prop_findMax :: IntSet -> Property +prop_findMax a = not (null a) ==> findMax a == Set.findMax (toSet a) + +prop_deleteMin :: IntSet -> Property +prop_deleteMin a = not (null a) ==> toSet (deleteMin a) == Set.deleteMin (toSet a) + +prop_deleteMax :: IntSet -> Property +prop_deleteMax a = not (null a) ==> toSet (deleteMax a) == Set.deleteMax (toSet a) + +prop_deleteFindMin :: IntSet -> Property +prop_deleteFindMin a = not (null a) ==> (x, toSet y) == Set.deleteFindMin (toSet a) where + (x, y) = deleteFindMin a + +prop_deleteFindMax :: IntSet -> Property +prop_deleteFindMax a = not (null a) ==> (x, toSet y) == Set.deleteFindMax (toSet a) where + (x, y) = deleteFindMax a + +prop_maxView :: IntSet -> Bool +prop_maxView a = Prelude.map (\(x, y) -> (x, toSet y)) (maxView a) == Set.maxView (toSet a) + +prop_minView :: IntSet -> Bool +prop_minView a = Prelude.map (\(x, y) -> (x, toSet y)) (minView a) == Set.minView (toSet a) + +prop_map :: (Int -> Int) -> IntSet -> Bool +prop_map a b = toSet (map a b) == Set.map a (toSet b) + +prop_fold :: (Int -> Int -> Int) -> Int -> IntSet -> Bool +prop_fold a b c = fold a b c == Set.fold a b (toSet c) + +-- The documentation for fold asserts this test. +prop_fold2 :: IntSet -> Bool +prop_fold2 set = elems set == fold (:) [] set + +prop_elems :: IntSet -> Bool +prop_elems a = elems a == Set.elems (toSet a) + +prop_toList :: IntSet -> Bool +prop_toList a = toList a == Set.toList (toSet a) + +prop_fromList :: [Int] -> Bool +prop_fromList a = toSet (fromList a) == Set.fromList a + +prop_toAscList :: IntSet -> Bool +prop_toAscList a = toAscList a == Set.toAscList (toSet a) + +prop_fromAscList :: [Int] -> Bool +prop_fromAscList a = toSet (fromAscList b) == Set.fromAscList b where + b = List.sort a + +prop_fromDistinctAscList :: IntSet -> Bool +prop_fromDistinctAscList a = toSet (fromDistinctAscList b) == Set.fromDistinctAscList b where + b = toAscList a + +prop_compare :: IntSet -> IntSet -> Bool +prop_compare a b = compare a b == compare (toSet a) (toSet b) + +prop_showsPrec :: Int -> IntSet -> String -> Bool +prop_showsPrec a b c = showsPrec a b c == showsPrec a (toSet b) c + +test_all = do + qcheck prop_Single + qcheck prop_InsertDelete + qcheck prop_UnionInsert + qcheck prop_UnionAssoc + qcheck prop_UnionComm + qcheck prop_Diff + qcheck prop_Int + qcheck prop_Ordered + qcheck prop_List + qcheck prop_toSet + qcheck prop_bkbk + qcheck prop_null + qcheck prop_size + qcheck prop_member + qcheck prop_notMember + qcheck prop_isSubsetOf + qcheck prop_isSubsetOf2 + qcheck prop_isProperSubsetOf + qcheck prop_isProperSubsetOf2 + qcheck prop_empty + qcheck prop_singleton + qcheck prop_insert + qcheck prop_delete + qcheck prop_union + qcheck prop_unions + qcheck prop_difference + qcheck prop_intersection + qcheck prop_filter + qcheck prop_partition + qcheck prop_split + qcheck prop_splitMember + qcheck prop_findMin + qcheck prop_findMax + qcheck prop_deleteMin + qcheck prop_deleteMax + qcheck prop_deleteFindMin + qcheck prop_deleteFindMax + qcheck prop_maxView + qcheck prop_minView + qcheck prop_map + qcheck prop_fold + qcheck prop_fold2 + qcheck prop_elems + qcheck prop_toList + qcheck prop_fromList + qcheck prop_toAscList + qcheck prop_fromAscList + qcheck prop_fromDistinctAscList + qcheck prop_compare + qcheck prop_showsPrec + qcheck prop_valid_bkbk + qcheck prop_valid_empty + qcheck prop_valid_singleton + qcheck prop_valid_insert + qcheck prop_valid_delete + qcheck prop_valid_union + qcheck prop_valid_unions + qcheck prop_valid_difference + qcheck prop_valid_intersection + qcheck prop_valid_filter + qcheck prop_valid_partition + qcheck prop_valid_split + qcheck prop_valid_splitMember + qcheck prop_valid_deleteMin + qcheck prop_valid_deleteMax + qcheck prop_valid_deleteFindMin + qcheck prop_valid_deleteFindMax + qcheck prop_valid_maxView + qcheck prop_valid_minView + qcheck prop_valid_map + qcheck prop_valid_fromList + qcheck prop_valid_fromAscList + qcheck prop_valid_fromDistinctAscList } Context: [Fix a link in haddock docs Ian Lynagh **20071126184450] [Fix some URLs Ian Lynagh **20071126214233] [Add tiny regression test David Benbennick **20071113045358] [Fix ticket 1762 David Benbennick **20071111201939] [Specify build-type: Simple Duncan Coutts **20071018125404] [Add a boring file Ian Lynagh **20070913204647] [TAG 2007-09-13 Ian Lynagh **20070913215901] Patch bundle hash: 81cd649b2d127d179f8a70c68b0588c93debd934 From vigalchin at gmail.com Mon Dec 3 00:00:25 2007 From: vigalchin at gmail.com (Galchin Vasili) Date: Sun Dec 2 23:56:02 2007 Subject: who develops and maintains the Unix package? In-Reply-To: <5ae4f2ba0712022049lf850757y9eb06be57a6adfbc@mail.gmail.com> References: <5ae4f2ba0712022049lf850757y9eb06be57a6adfbc@mail.gmail.com> Message-ID: <5ae4f2ba0712022100s79691982hd6a59df5462708e3@mail.gmail.com> Hello, > > I am starting to get in the groove related to runhaskell -- > config/builds on top of cygwin (I haven't had time to carve up hard drive > and install Linux). > > In any case, I really want to get the Unix package to build on > cgywin (as advertised at > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/unix-2.2.0.0). > When i do "runhaskell Setup.lhs configure" > things seem to go fine, .log fine is clean, and pertinent cygwin include > files like times.h are found, but when i do a "runhaskell Setup.lhs build" > then the include files that are allegedly found during the configure > "probe" cannot be found. ???? > > 1) During the "runhaskell Setup.lhs build" step, what human readable > file > is used and contains paths to the cygwin Posix include file > directories? 2) thatis foloowing is a better approach for me .. => > > 2) Somebody obviously put " (except under Cygwin)". Can you point at > who made this claim and why? > > > Kind regards, Vasya > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20071202/1b6fe0dd/attachment.htm From dons at galois.com Mon Dec 3 00:13:04 2007 From: dons at galois.com (Don Stewart) Date: Mon Dec 3 00:08:51 2007 Subject: QuickCheck properties for IntSet In-Reply-To: References: Message-ID: <20071203051304.GK13662@scytale.galois.com> dbenbenn: > Here's a patch to IntSet.hs that adds many QuickCheck properties. It > adds properties testing almost all of the public interface of IntSet, > and also properties testing that the data type invariants are never > broken. (The patch doesn't test the Data, Eq, Monoid, Read, or > Typeable instances.) > > Also, this patch removes a helper function, foldlStrict, and replaces > it with calls to Data.List.foldl'. > > I have two questions: > > 1) Is this the right way to submit patches? Thanks so much David, for taking the time to do this! Getting the testing up to date on the somewhat-forgotten base code is really important. Ian, can we get these into the base library testsuite? Have you tried getting some code coverage for you testsuite, btw? (Compile with -fhpc, and then run "hpc report" on the resulting .tix file, to get numbers on how thorough the coverage is) -- Don From kahl at cas.mcmaster.ca Mon Dec 3 00:10:12 2007 From: kahl at cas.mcmaster.ca (kahl@cas.mcmaster.ca) Date: Mon Dec 3 00:09:24 2007 Subject: Proposal: Bounded instance for IntSet (ticket #1953) In-Reply-To: <20071202235336.GA20802@soi.city.ac.uk> (message from Ross Paterson on Sun, 2 Dec 2007 23:53:36 +0000) References: <20071202235336.GA20802@soi.city.ac.uk> Message-ID: <20071203051012.14459.qmail@schroeder.cas.mcmaster.ca> On Sun, 2 Dec 2007, at 23:53:36 +0000, Ross Paterson wrote: > > On Sun, Dec 02, 2007 at 03:45:40PM -0800, David Benbennick wrote: > > I propose to add a Bounded instance to IntSet.hs. > > > > IntSet is in Ord, and there are only finitely many instances of > > IntSet. Therefore there is a min IntSet and a max IntSet. It turns out > > these bounds are very simple: > > > > instance Bounded IntSet where > > minBound = empty > > maxBound = singleton maxBound > > These are the minimum and maximum under the Ord instance (also for Set), > but what is the intuition behind that ordering? In my opinion, the class ``Ord'' is not particularly heavy on intuition; it just provides an interface to ``the standard linear ordering'' for each of its types, so that these types can be used for keys in Data.Map's, etc. Not many types are naturally understood as linearly ordered, but most of those types should still be usable for keys in maps. Bounded happens to be defined over Ord, so such instances make sense for whatever uses people want to put Bounded to. Wolfram From dons at galois.com Mon Dec 3 00:54:05 2007 From: dons at galois.com (Don Stewart) Date: Mon Dec 3 00:49:48 2007 Subject: [Haskell-cafe] Possible Improvements In-Reply-To: <4683d9370712022135o5bf75cd1x3cbbf6567382813e@mail.gmail.com> References: <7.0.1.0.0.20071203051129.01b16300@ntlworld.com> <20071203052330.GM13662@scytale.galois.com> <4683d9370712022135o5bf75cd1x3cbbf6567382813e@mail.gmail.com> Message-ID: <20071203055405.GN13662@scytale.galois.com> catamorphism: > On 12/2/07, Don Stewart wrote: > > prstanley: > > > Hi > > > data Tree = Leaf Int | Node Tree Int Tree > > > > > > occurs :: Int -> Tree -> Bool > > > occurs m (Leaf n) = m == n > > > occurs m (Node l n r) = m == n || occurs m l || occurs m r > > > > > > It works but I'd like to know if it can be improved in any way. > > > > You could probably get away with: > > > > data Tree = Leaf !Int | Node Tree !Int Tree > > > > but that's a minor issue. > > > > IMO, there's no reason to even think about putting in the strictness > annotations unless you've identified this datatype as part of a > performance bottleneck in production code. Otherwise, there's no need > to clutter your code and your mind with them :-) Very true ("a minor issue"). However, *rarely* do you want lazines in the atomic types (Int,Char,Word,Integer, et al) A little test: main = do n <- getArgs >>= readIO . head let t = make (n*2) n print (check t) make :: Int -> Int -> Tree make i 0 = Node (Leaf 0) i (Leaf 0) make i d = Node (make (i2-1) d2) i (make i2 d2) where i2 = 2*i d2 = d-1 check :: Tree -> Int check (Leaf _) = 0 check (Node l i r) = i + check l - check r Fully lazy: data Tree = Leaf Int | Node Tree Int Tree $ time ./A 25 49 ./A 25 18.20s user 0.04s system 99% cpu 18.257 total ^^^^^^ 3556K heap use. Strict in the elements, lazy in the spine: data Tree = Leaf !Int | Node Tree !Int Tree $ time ./A 25 49 ./A 25 14.41s user 0.03s system 99% cpu 14.442 total ^^^^^^ 3056K heap use. You'll be hard pressed to do better in C here. Finally, strict in the spine and elements: data Tree = Leaf !Int | Node !Tree !Int !Tree $ time ./A 25 A: out of memory (requested 1048576 bytes) ./A 25 11.46s user 2.60s system 97% cpu 14.379 total 657M heap use ^^^^ Lesson: * Full strictness == teh suckness. * Mixed lazy and strict == flexible and efficient data types. Makes me wonder why Map is strict in the spine, data Map k a = Tip | Bin {-# UNPACK #-} !Size !k a !(Map k a) !(Map k a) Anyone know? Cheers, Don From dons at galois.com Mon Dec 3 01:10:27 2007 From: dons at galois.com (Don Stewart) Date: Mon Dec 3 01:06:14 2007 Subject: [Haskell-cafe] Possible Improvements In-Reply-To: <20071203055405.GN13662@scytale.galois.com> References: <7.0.1.0.0.20071203051129.01b16300@ntlworld.com> <20071203052330.GM13662@scytale.galois.com> <4683d9370712022135o5bf75cd1x3cbbf6567382813e@mail.gmail.com> <20071203055405.GN13662@scytale.galois.com> Message-ID: <20071203061027.GA14502@scytale.galois.com> > Fully lazy: > > data Tree = Leaf Int | Node Tree Int Tree > > $ time ./A 25 > 49 > ./A 25 18.20s user 0.04s system 99% cpu 18.257 total > ^^^^^^ > 3556K heap use. > > Strict in the elements, lazy in the spine: > > data Tree = Leaf !Int | Node Tree !Int Tree > > $ time ./A 25 > 49 > ./A 25 14.41s user 0.03s system 99% cpu 14.442 total > ^^^^^^ > 3056K heap use. And, oh, element strict, with -funbox-strict-fields, $ time ./A 25 49 ./A 25 12.25s user 0.01s system 99% cpu 12.346 total -- Don From dons at galois.com Mon Dec 3 01:31:37 2007 From: dons at galois.com (Don Stewart) Date: Mon Dec 3 01:27:22 2007 Subject: [Haskell-cafe] Possible Improvements In-Reply-To: <20071203055405.GN13662@scytale.galois.com> References: <7.0.1.0.0.20071203051129.01b16300@ntlworld.com> <20071203052330.GM13662@scytale.galois.com> <4683d9370712022135o5bf75cd1x3cbbf6567382813e@mail.gmail.com> <20071203055405.GN13662@scytale.galois.com> Message-ID: <20071203063137.GA14530@scytale.galois.com> dons: > > * Full strictness == teh suckness. > * Mixed lazy and strict == flexible and efficient data types. > > Makes me wonder why Map is strict in the spine, > > data Map k a = Tip > | Bin {-# UNPACK #-} !Size !k a !(Map k a) !(Map k a) > Spencer points out that being sized-balanced, subtree sizes must be computed on insertion, so may as well make the structure spine strict anyway. -- Don From vigalchin at gmail.com Mon Dec 3 02:30:13 2007 From: vigalchin at gmail.com (Galchin Vasili) Date: Mon Dec 3 02:25:50 2007 Subject: more info on building the Unix package on cygwin Message-ID: <5ae4f2ba0712022330q5785720cy2b3bbccc282b38ba@mail.gmail.com> Hello, I put an ugly kludge(on my laptop) in the unix.cabal file For the includes-dir "attribute" I explicited specified the path to the cygwin include directory. The Unix package build gets farther and then gets errors. At this point, it appears that the cygwin sys/types.h has a "bug" .. id_t is not defined but id_t is referenced by sys/resources.h/(getpriority/setpriority). Please see see http://www.opengroup.org/onlinepubs/000095399/functions/setpriority.html for getpriority function signature. In any case, I want compare the Linux sys/types.h include. To summarize: 1) I am just learning about the .cabal file format from the Cabal .pdf. In any case, it appears that for the case of cygwin that unix.cabal is deficient. 2) It also appears that the cygwin sys/types.h failed to defined id_t which is needed by sys/resources.h which in turn is needed by System/Posix/DynamicLinker/Module.hsc (error at line 57 where HsUnix.h is refd .. and in HsUnix.h at line # 38 sys/resource.h is referenced.) I can provide a stderr "log". Kind regards, Vasya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20071203/dcf3fb42/attachment.htm From johan.tibell at gmail.com Mon Dec 3 03:43:16 2007 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon Dec 3 03:38:55 2007 Subject: [Haskell-cafe] Possible Improvements In-Reply-To: <1196664351.5471.13.camel@derek-laptop> References: <7.0.1.0.0.20071203051129.01b16300@ntlworld.com> <20071203052330.GM13662@scytale.galois.com> <4683d9370712022135o5bf75cd1x3cbbf6567382813e@mail.gmail.com> <20071203055405.GN13662@scytale.galois.com> <1196664351.5471.13.camel@derek-laptop> Message-ID: <90889fe70712030043g3c104b9bpfd3f221734441afa@mail.gmail.com> > I agree that (in this context, beginning learning Haskell) it is a > somewhat minor issue. But I disagree that this is something you should > ignore until it becomes a problem and I do think that it should be part > of learning Haskell. Properly using strictness is an important part of > using Haskell. It makes the difference between code that stack > overflows and code that doesn't, code that takes 100 seconds and code > that takes 10, code that uses 3MB of RAM and code that uses 600. At > least the first of these is not, in my mind, the difference between > "optimized" and "unoptimized", but rather the difference between correct > and incorrect. Writing better code at the beginning is much easier than > trying to figure out what the problem is later. Furthermore, writing > better code is not more difficult. In this case it merely means adding > two characters. Of late, the "rules of thumb" for this sort of thing > are becoming more widely known. Such things need to be "instinctively" > part of how you write code, much like writing code tail-recursively or > not using (++) left associatively. It's not that you should immediately > know that this is better, but (more strongly) that you should not even > think of the worse ways to begin with in many cases. It would be great if someone could exemplify these "rules of thumb", e.g. "Primitive types such as Int should be strict unless in the three canonical examples X, Y and Z." My strictness radar is still quite poor and I feel I can't make informed decisions on when I need to make something more strict or lazy. -- Johan From ketil+haskell at ii.uib.no Mon Dec 3 04:48:33 2007 From: ketil+haskell at ii.uib.no (Ketil Malde) Date: Mon Dec 3 04:44:12 2007 Subject: [Haskell-cafe] Possible Improvements In-Reply-To: <90889fe70712030043g3c104b9bpfd3f221734441afa@mail.gmail.com> (Johan Tibell's message of "Mon\, 3 Dec 2007 09\:43\:16 +0100") References: <7.0.1.0.0.20071203051129.01b16300@ntlworld.com> <20071203052330.GM13662@scytale.galois.com> <4683d9370712022135o5bf75cd1x3cbbf6567382813e@mail.gmail.com> <20071203055405.GN13662@scytale.galois.com> <1196664351.5471.13.camel@derek-laptop> <90889fe70712030043g3c104b9bpfd3f221734441afa@mail.gmail.com> Message-ID: <87myssglce.fsf@nmd9999.imr.no> "Johan Tibell" writes: > It would be great if someone could exemplify these "rules of thumb", > e.g. "Primitive types such as Int should be strict unless in the three > canonical examples X, Y and Z." My strictness radar is still quite > poor and I feel I can't make informed decisions on when I need to make > something more strict or lazy. I find that I often need to add strictness when: left thumb) parsing [Char] into something more compact, i.e. almost all cases. right thumb) storing data into maps, especially when the values are produced by multiple updates - i.e. doing word frequency counts. -k -- If I haven't seen further, it is by standing in the footprints of giants From lemming at henning-thielemann.de Mon Dec 3 06:10:04 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Dec 3 06:05:39 2007 Subject: Proposal: Bounded instance for IntSet (ticket #1953) In-Reply-To: <20071203051012.14459.qmail@schroeder.cas.mcmaster.ca> References: <20071202235336.GA20802@soi.city.ac.uk> <20071203051012.14459.qmail@schroeder.cas.mcmaster.ca> Message-ID: Fax +49 - 345 - 55 27033 On Mon, 3 Dec 2007 kahl@cas.mcmaster.ca wrote: > On Sun, 2 Dec 2007, at 23:53:36 +0000, Ross Paterson wrote: > > > > On Sun, Dec 02, 2007 at 03:45:40PM -0800, David Benbennick wrote: > > > I propose to add a Bounded instance to IntSet.hs. > > > > > > IntSet is in Ord, and there are only finitely many instances of > > > IntSet. Therefore there is a min IntSet and a max IntSet. It turns out > > > these bounds are very simple: > > > > > > instance Bounded IntSet where > > > minBound = empty > > > maxBound = singleton maxBound > > > > These are the minimum and maximum under the Ord instance (also for Set), > > but what is the intuition behind that ordering? > > In my opinion, the class ``Ord'' is not particularly heavy on intuition; > it just provides an interface to ``the standard linear ordering'' > for each of its types, > so that these types can be used for keys in Data.Map's, etc. > > Not many types are naturally understood as linearly ordered, > but most of those types should still be usable for keys in maps. I already told about by scepticism about using Ord for keys of maps and sets: http://www.haskell.org/pipermail/libraries/2007-April/007411.html From lemming at henning-thielemann.de Mon Dec 3 06:16:03 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Dec 3 06:11:45 2007 Subject: QuickCheck properties for IntSet In-Reply-To: <20071203051304.GK13662@scytale.galois.com> References: <20071203051304.GK13662@scytale.galois.com> Message-ID: On Sun, 2 Dec 2007, Don Stewart wrote: > dbenbenn: > > Here's a patch to IntSet.hs that adds many QuickCheck properties. It > > adds properties testing almost all of the public interface of IntSet, > > and also properties testing that the data type invariants are never > > broken. (The patch doesn't test the Data, Eq, Monoid, Read, or > > Typeable instances.) > > > > Also, this patch removes a helper function, foldlStrict, and replaces > > it with calls to Data.List.foldl'. > > > > I have two questions: > > > > 1) Is this the right way to submit patches? > > Thanks so much David, for taking the time to do this! Getting the > testing up to date on the somewhat-forgotten base code is really > important. Me too. Whenever I used IntSet, I discovered a bug ... From gale at sefer.org Mon Dec 3 07:04:55 2007 From: gale at sefer.org (Yitzchak Gale) Date: Mon Dec 3 07:00:55 2007 Subject: Proposal: Bounded instance for IntSet (ticket #1953) In-Reply-To: References: <20071202235336.GA20802@soi.city.ac.uk> <20071203051012.14459.qmail@schroeder.cas.mcmaster.ca> Message-ID: <2608b8a80712030404pb890581qabb261df4717b789@mail.gmail.com> David Benbennick wrote: > I propose to add a Bounded instance to IntSet.hs. I am opposed to this proposal, unless someone comes up with some important use cases. Unfortunately, there is still no way to control export of instances. So libraries should avoid defining instances unless there is a compelling reason to do so. We need to be reasonably certain that the usefulness of the instance will overwhelm any unforeseen namespace pollution problems that it may cause. In this case, the Ord instance is not really natural; it is defined for technical reasons for use by the library itself (and its friends). The library has no need for a Bounded instance, so why should we prevent people from defining one for some other purpose? -Yitz From lemming at henning-thielemann.de Mon Dec 3 07:19:40 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Dec 3 07:15:16 2007 Subject: Proposal: Bounded instance for IntSet (ticket #1953) In-Reply-To: <2608b8a80712030404pb890581qabb261df4717b789@mail.gmail.com> References: <20071202235336.GA20802@soi.city.ac.uk> <20071203051012.14459.qmail@schroeder.cas.mcmaster.ca> <2608b8a80712030404pb890581qabb261df4717b789@mail.gmail.com> Message-ID: On Mon, 3 Dec 2007, Yitzchak Gale wrote: > David Benbennick wrote: > > I propose to add a Bounded instance to IntSet.hs. > > I am opposed to this proposal, unless someone > comes up with some important use cases. > > Unfortunately, there is still no way to control export > of instances. You can put instances into a separate module (and get GHC warnings about that :-) But it is not sensible to have different instances for the same type and class, because they will collide sooner or later. > So libraries should avoid defining instances unless there is a > compelling reason to do so. We need to be reasonably certain that the > usefulness of the instance will overwhelm any unforeseen namespace > pollution problems that it may cause. I think there is no much sense in defining instances privately in code that uses a class definition from a library, because the custom instance in turn may break other modules. In the past it happened for me at each GHC upgrade, that instances that I defined privately (like Show for FiniteMap) collide with new instances defined in the imported standard module. From gale at sefer.org Mon Dec 3 07:47:00 2007 From: gale at sefer.org (Yitzchak Gale) Date: Mon Dec 3 07:42:38 2007 Subject: Using Ord for keys of maps and sets Message-ID: <2608b8a80712030447v4ff45a3dj77feb2e566fa6263@mail.gmail.com> Henning Thielemann wrote: > I already told about by scepticism about using Ord for keys of maps and > sets: > http://www.haskell.org/pipermail/libraries/2007-April/007411.html Yes. There are a number of different scenarios for the ordering that you want to use for indexing: 1. A default ordering for the type that is a natural ordering. 2. A default ordering for indexing that is not a natural ordering. 3. An application-specific ordering. 4. More than one ordering for the same type, determined statically. 5. More than one ordering for the same type, determined dynamically, i.e., parameterized orderings. My experience has been that all of these cases do come up quite often in real life. One solution would be to have Data.Map.Indexable, etc. as alternatives using Indexable instead of Ord, so that we could avoid newtype wrapping in case 2. We could allow for case 3 by not providing any default instances for Indexable. Or we could provide default instances in a separate module, Data.Indexable.Instances (or something), that you could choose whether or not to import. Newtype wrapping is still required in case 4, so Indexable doesn't add much here. We have not yet said anything helpful about case 5. -Yitz From gale at sefer.org Mon Dec 3 08:32:52 2007 From: gale at sefer.org (Yitzchak Gale) Date: Mon Dec 3 08:28:29 2007 Subject: Proposal: Bounded instance for IntSet (ticket #1953) In-Reply-To: References: <20071202235336.GA20802@soi.city.ac.uk> <20071203051012.14459.qmail@schroeder.cas.mcmaster.ca> <2608b8a80712030404pb890581qabb261df4717b789@mail.gmail.com> Message-ID: <2608b8a80712030532l4569b020t6233851dd7bf3df5@mail.gmail.com> Henning Thielemann wrote: > ...it is not sensible to have different instances for the same > type and class, because they will collide sooner or later. True. That is why libraries should not define an instance at all, unless they are quite certain that it is by far the most important instance that anyone will ever want to use. Here is an example: Control.Monad.Error defines a Monad instance for Either. I understand why that seemed sensible at the time. But the Either type is useful for many other things, too, and now it can *only* be used as an exception type in a monadic setting. If I had to pick just one usage for Either as a monad, it would be as an exit monad. I would use a different name for the exception monad, not the other way around. But now I'm stuck - if I want to use Control.Monad.Error at all, I have to use its crippled monad instance for Either. > I think there is no much sense in defining instances privately in code > that uses a class definition from a library, because the custom instance > in turn may break other modules. In the past it happened for me at each > GHC upgrade, that instances that I defined privately (like Show for > FiniteMap) collide with new instances defined in the imported standard > module. OK, so not only should libraries avoid defining instances - users should also think carefully before defining them. Because of this current limitation in Haskell's module system, instances are like the magic in the Sorcerer's Apprentice - very powerful, and unstoppable, for good and for bad. (This is ticket #19 in Haskell', marked as "maybe". Vote for issue 19!) Regards, Yitz From lemming at henning-thielemann.de Mon Dec 3 08:42:11 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Dec 3 08:37:47 2007 Subject: Using Ord for keys of maps and sets In-Reply-To: <2608b8a80712030447v4ff45a3dj77feb2e566fa6263@mail.gmail.com> References: <2608b8a80712030447v4ff45a3dj77feb2e566fa6263@mail.gmail.com> Message-ID: On Mon, 3 Dec 2007, Yitzchak Gale wrote: > Henning Thielemann wrote: > > I already told about by scepticism about using Ord for keys of maps and > > sets: > > http://www.haskell.org/pipermail/libraries/2007-April/007411.html > > Yes. There are a number of different scenarios for the > ordering that you want to use for indexing: > > 1. A default ordering for the type that is a natural ordering. > > 2. A default ordering for indexing that is not a natural > ordering. > > 3. An application-specific ordering. > > 4. More than one ordering for the same type, determined > statically. > > 5. More than one ordering for the same type, determined > dynamically, i.e., parameterized orderings. > > My experience has been that all of these cases do come > up quite often in real life. > > One solution would be to have Data.Map.Indexable, etc. > as alternatives using Indexable instead of Ord, so that > we could avoid newtype wrapping in case 2. > > We could allow for case 3 by not providing any default > instances for Indexable. This would obstruct 'start GHCi and play around' sessions, since you cannot create a set of something on the fly. (However, GHCi could still be adapted.) > Or we could provide default instances in a separate module, > Data.Indexable.Instances (or something), that you could choose whether > or not to import. > > Newtype wrapping is still required in case 4, so > Indexable doesn't add much here. > > We have not yet said anything helpful about case 5. Still, later in the above thread, Johannes Waldmann throws in Local Instances: http://www.haskell.org/pipermail/libraries/2007-April/007416.html From lemming at henning-thielemann.de Mon Dec 3 08:58:45 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Dec 3 08:54:27 2007 Subject: Proposal: Bounded instance for IntSet (ticket #1953) In-Reply-To: <2608b8a80712030532l4569b020t6233851dd7bf3df5@mail.gmail.com> References: <20071202235336.GA20802@soi.city.ac.uk> <20071203051012.14459.qmail@schroeder.cas.mcmaster.ca> <2608b8a80712030404pb890581qabb261df4717b789@mail.gmail.com> <2608b8a80712030532l4569b020t6233851dd7bf3df5@mail.gmail.com> Message-ID: On Mon, 3 Dec 2007, Yitzchak Gale wrote: > Henning Thielemann wrote: > > ...it is not sensible to have different instances for the same > > type and class, because they will collide sooner or later. > > True. That is why libraries should not define an instance > at all, unless they are quite certain that it is by far the most > important instance that anyone will ever want to use. > > Here is an example: Control.Monad.Error defines a Monad > instance for Either. I understand why that seemed sensible > at the time. But the Either type is useful for many other things, > too, and now it can *only* be used as an exception type in > a monadic setting. If I had to pick just one usage for Either > as a monad, it would be as an exit monad. I would use a > different name for the exception monad, not the other way > around. But now I'm stuck - if I want to use Control.Monad.Error > at all, I have to use its crippled monad instance for Either. I think the problem here is, that library designers wanted to save work by (ab)using Either for errors. They should have defined an Error type which shares similarities with Either but is a distinct type and its occurence tells the reader that it is not about arbitrary alternatives but about error handling. What concerns instances - after I managed to understand the "orphan instance" warnings of GHC I learnt to like GHC's rule of warning about instances: Instances should be defined in the module where the class or the instance type is defined. If I import a standard type and a standard class with a natural instance declaration I expect that this instance already exists. E.g. in GHCi-6.4.1 Prelude> Test.QuickCheck.test (\xl yl -> let x = Data.Set.fromList (xl::[Int]); y = Data.Set.fromList yl in Data.Set.union x y == Data.Set.union y x) Loading package QuickCheck-1.0 ... linking ... done. OK, passed 100 tests. This small example already uses several predefined instance: Ord instance for Int, Eq instance for Data.Set.Set, Arbitrary for Int and List, Show instances for them. The first two are rather straightforward, the second two are a somehow arbitrary, although useful. Of course I like to write Prelude> Test.QuickCheck.test (\x y -> Data.Set.union x y == Data.Set.union y (x::Data.Set.Set Int)) but :1:0: No instance for (Test.QuickCheck.Arbitrary (Data.Set.Set Int)) arising from use of `Test.QuickCheck.test' at :1:0-19 Probable fix: add an instance declaration for (Test.QuickCheck.Arbitrary (Data.Set.Set Int)) In the definition of `it': it = Test.QuickCheck.test (\ x y -> (Data.Set.union x y) == (Data.Set.union y (x :: Data.Set.Set Int))) But I think, since List is an instance of Arbitrary, Set can also be one, based on the List instance. From gale at sefer.org Mon Dec 3 09:04:09 2007 From: gale at sefer.org (Yitzchak Gale) Date: Mon Dec 3 08:59:44 2007 Subject: Using Ord for keys of maps and sets In-Reply-To: References: <2608b8a80712030447v4ff45a3dj77feb2e566fa6263@mail.gmail.com> Message-ID: <2608b8a80712030604i6e95efa4s39c8685d74d6efc7@mail.gmail.com> I wrote: >> We could allow for case 3 by not providing any default >> instances for Indexable. Henning Thielemann wrote: > This would obstruct 'start GHCi and play around' sessions, since you > cannot create a set of something on the fly. (However, GHCi could still be > adapted.) Yes. I am suggesting also leaving the current versions that use Ord, so we are no worse off with that than we were before, at least. > Still, later in the above thread, Johannes Waldmann throws in Local > Instances: > http://www.haskell.org/pipermail/libraries/2007-April/007416.html Ah, yes. That would be great! I would especially like it for GHCI - in general, not just because of the special case you mentioned above. But this has come up before. There are people who are not sure about this feature, because of some ambiguous and/or confusing cases that can come up when you redefine an instance that already exists in an enclosing context. And anyway - this is a serious language change. It will at best take time. Your Indexable class could be used right now to make a lot of the most common cases much easier to handle. -Yitz From dbenbenn at gmail.com Mon Dec 3 10:22:48 2007 From: dbenbenn at gmail.com (David Benbennick) Date: Mon Dec 3 10:18:27 2007 Subject: Proposal: Bounded instance for IntSet (ticket #1953) In-Reply-To: <2608b8a80712030404pb890581qabb261df4717b789@mail.gmail.com> References: <20071202235336.GA20802@soi.city.ac.uk> <20071203051012.14459.qmail@schroeder.cas.mcmaster.ca> <2608b8a80712030404pb890581qabb261df4717b789@mail.gmail.com> Message-ID: On 12/3/07, Yitzchak Gale wrote: > In this case, the Ord instance is not really natural; it is defined > for technical reasons for use by the library itself (and its > friends). The library has no need for a Bounded instance, so why > should we prevent people from defining one for some other purpose? Note that in one sense, people are already prevented from defining a different Bounded instance. Any Bounded instance other than the one suggested in this proposal would fail to obey the axioms of the Bounded class. In other words, there is a unique largest element, and a unique smallest element, an no one can legitimately define a different Bounded instance. Given that the Bounded instance is uniquely defined, I think it is more convenient to have it defined by the library than to have to manually define it in every program that uses it. From gale at sefer.org Mon Dec 3 10:51:06 2007 From: gale at sefer.org (Yitzchak Gale) Date: Mon Dec 3 10:46:47 2007 Subject: Proposal: Bounded instance for IntSet (ticket #1953) In-Reply-To: References: <20071202235336.GA20802@soi.city.ac.uk> <20071203051012.14459.qmail@schroeder.cas.mcmaster.ca> <2608b8a80712030404pb890581qabb261df4717b789@mail.gmail.com> Message-ID: <2608b8a80712030751m3eb3fa23y1236be0a699ea1ad@mail.gmail.com> Yitzchak Gale wrote: >> In this case, the Ord instance is not really natural; it is defined >> for technical reasons for use by the library itself (and its >> friends). The library has no need for a Bounded instance, so why >> should we prevent people from defining one for some other purpose? David Benbennick wrote: > Note that in one sense, people are already prevented from defining a > different Bounded instance. Any Bounded instance other than the one > suggested in this proposal would fail to obey the axioms of the > Bounded class. In other words, there is a unique largest element, and > a unique smallest element, an no one can legitimately define a > different Bounded instance. Where are these axioms? I only see the Haddocks in the Prelude: "Ord is not a superclass of Bounded since types that are not totally ordered may also have upper and lower bounds." I think that is the case here. There is no unique notion of order for this type. The Ord instance only exists so that you can insert these things into containers. So Ord is used up now for this type, a pity. Why should the fact that we want to be able to use containers force us to clobber the Bounded class as well? I think that Henning's point is well-taken. This use of Ord in the Data. series has effectively changed the semantics of Ord. If a type has an Ord instance, it might mean that the type is ordered, but it also might mean only that the type has been enabled for convenient use with containers. If we allow the use of an alternative class for key indexing for types that are not naturally ordered, as Henning suggests, then we will be able to impose a relationship between Bounded and Ord as you suggest. Regards, Yitz From dbenbenn at gmail.com Mon Dec 3 11:08:58 2007 From: dbenbenn at gmail.com (David Benbennick) Date: Mon Dec 3 11:04:39 2007 Subject: Proposal: Bounded instance for IntSet (ticket #1953) In-Reply-To: <2608b8a80712030751m3eb3fa23y1236be0a699ea1ad@mail.gmail.com> References: <20071202235336.GA20802@soi.city.ac.uk> <20071203051012.14459.qmail@schroeder.cas.mcmaster.ca> <2608b8a80712030404pb890581qabb261df4717b789@mail.gmail.com> <2608b8a80712030751m3eb3fa23y1236be0a699ea1ad@mail.gmail.com> Message-ID: On 12/3/07, Yitzchak Gale wrote: > David Benbennick wrote: > > Note that in one sense, people are already prevented from defining a > > different Bounded instance. Any Bounded instance other than the one > > suggested in this proposal would fail to obey the axioms of the > > Bounded class. In other words, there is a unique largest element, and > > a unique smallest element, an no one can legitimately define a > > different Bounded instance. > > Where are these axioms? I only see the Haddocks in the Prelude: > > "Ord is not a superclass of Bounded since types that are not > totally ordered may also have upper and lower bounds." See http://haskell.org/ghc/docs/latest/html/libraries/base-3.0.0.0/Prelude.html#t%3ABounded The first sentence there says "The Bounded class is used to name the upper and lower limits of a type". In other words, you can't just pick any old values for minValue and maxValue. From isaacdupree at charter.net Mon Dec 3 11:34:30 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Mon Dec 3 11:31:34 2007 Subject: Proposal: Max and Min for Monoid (ticket # 1952) In-Reply-To: <20071202232554.GA20705@soi.city.ac.uk> References: <20071202232554.GA20705@soi.city.ac.uk> Message-ID: <47543016.1040908@charter.net> Ross Paterson wrote: > Funny, I was thinking of proposing a Max type that adjoined a synthetic > identity, as we did in the finger tree paper: > > data Max a = NoMax | Max a > deriving (Eq, Ord, Read, Show) > > instance Ord a => Monoid (Max a) where > mempty = NoMax > NoMax `mappend` b = b > a `mappend` NoMax = a > Max x `mappend` Max y = Max (x `max` y) > > and similarly for Min. One could even define > > getMax :: Bounded a => Max a -> a > getMax NoMax = minBound > getMax (Max x) = x I was thinking you could get that with some version of the (Maybe (Max a)) Monoid, but you are right: your version doesn't require (a) to be Bounded, thus works with Integers etc. Isaac From kahl at cas.mcmaster.ca Mon Dec 3 11:37:49 2007 From: kahl at cas.mcmaster.ca (kahl@cas.mcmaster.ca) Date: Mon Dec 3 11:36:58 2007 Subject: Proposal: Bounded instance for IntSet (ticket #1953) In-Reply-To: <2608b8a80712030404pb890581qabb261df4717b789@mail.gmail.com> (gale@sefer.org) References: <20071202235336.GA20802@soi.city.ac.uk> <20071203051012.14459.qmail@schroeder.cas.mcmaster.ca> <2608b8a80712030404pb890581qabb261df4717b789@mail.gmail.com> Message-ID: <20071203163749.8388.qmail@schroeder.cas.mcmaster.ca> Yitzchak Gale wrote: > > Unfortunately, there is still no way to control export > of instances. I have some modules that do nothing but export instances --- I even make the empty export list explicit... > > In this case, the Ord instance is not really natural; it is defined > for technical reasons for use by the library itself (and its > friends). The library has no need for a Bounded instance, so why > should we prevent people from defining one for some other purpose? Whereever this Ord instance is in scope, a Bounded instance has to conform with that. It even makes sense to define the Bounded instance for the explicit purpose of preventing people to roll their own semantically inconsistent Bounded instances, especially since the correct instance is obviously somewhat non-obvious ;-) One could of course consider to put both instances into a separate module Data.IntMap.Ord, so you can choose not to import that and roll your own instead. Wolfram From isaacdupree at charter.net Mon Dec 3 11:45:22 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Mon Dec 3 11:43:33 2007 Subject: Proposal: Max and Min for Monoid (ticket # 1952) In-Reply-To: <20071202232554.GA20705@soi.city.ac.uk> References: <20071202232554.GA20705@soi.city.ac.uk> Message-ID: <475432A2.1000404@charter.net> Ross Paterson wrote: > data Max a = NoMax | Max a > deriving (Eq, Ord, Read, Show) > and similarly for Min. data Min a = Min a | NoMin so that the deriving Ord works as expected The newtypes don't add a possible bottom, but data does... should (Max undefined) be non-bottom, or should the data types have strictness annotations perhaps? Isaac From haskell at list.mightyreason.com Mon Dec 3 13:41:27 2007 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Mon Dec 3 13:37:10 2007 Subject: Proposal: add "writer" Monad instance (,) o (Ticket #1951) In-Reply-To: References: Message-ID: <47544DD7.6090200@list.mightyreason.com> In State, the tuple order that is use is > > newtype State s a = State { > > runState :: (s -> (a, s)) > > } So I would expect you to use the same order for writer. This only changes (>>) below: > > instance Monoid o => Monad ((,) o) where > > return = (a,mempty) > > (a,o) >>= f = (a',o `mappend` o') where (a',o') = f a -- Chris From conal at conal.net Mon Dec 3 13:50:50 2007 From: conal at conal.net (Conal Elliott) Date: Mon Dec 3 13:46:26 2007 Subject: Proposal: add "writer" Monad instance (,) o (Ticket #1951) In-Reply-To: <47543445.9000105@mightyreason.com> References: <47543445.9000105@mightyreason.com> Message-ID: Hi Chris. I don't think that version could type-check. Try it out. - Conal On Dec 3, 2007 8:52 AM, Chris Kuklewicz wrote: > In State, the tuple order that is use is > > newtype State s a = State { > > runState :: (s -> (a, s)) > > } > > So I would expect you to use the same order for writer. This only > changes (>>) > below: > > > instance Monoid o => Monad ((,) o) where > > return = (a,mempty) > > (a,o) >>= f = (a',o `mappend` o') where (a',o') = f a > > -- > Chris > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20071203/41b0f24c/attachment-0001.htm From dbenbenn at gmail.com Mon Dec 3 15:29:23 2007 From: dbenbenn at gmail.com (David Benbennick) Date: Mon Dec 3 15:24:58 2007 Subject: QuickCheck properties for IntSet In-Reply-To: <20071203051304.GK13662@scytale.galois.com> References: <20071203051304.GK13662@scytale.galois.com> Message-ID: On 12/2/07, Don Stewart wrote: > Have you tried getting some code coverage for you testsuite, btw? > (Compile with -fhpc, and then run "hpc report" on the resulting .tix > file, to get numbers on how thorough the coverage is) Thanks for the suggestion! Here's what I get: 89% expressions used (1973/2214) 62% boolean coverage (69/110) 60% guards (62/103), 35 always True, 6 unevaluated 100% 'if' conditions (7/7) 100% qualifiers (0/0) 87% alternatives used (183/209) 96% local declarations used (26/27) 84% top-level declarations used (144/171) Next weekend I'll work on pushing these percentages up. I wish I could use QuickCheck to write an actual unit test: that is, an executable program that returns 0 on success, and non-zero on failure. Then we could put these properties in the tests/ directory, and have them automatically executed. Is anyone working on such a feature for QuickCheck? From conal at conal.net Mon Dec 3 15:38:09 2007 From: conal at conal.net (Conal Elliott) Date: Mon Dec 3 15:33:45 2007 Subject: Proposal: Max and Min for Monoid (ticket # 1952) In-Reply-To: <20071202232554.GA20705@soi.city.ac.uk> References: <20071202232554.GA20705@soi.city.ac.uk> Message-ID: Similarly, I'm using the following to get around type parameters that don't provide Bounded: data AddBounds a = MinBound | NoBound a | MaxBound deriving (Eq, Ord, Read, Show) instance Bounded (AddBounds a) where minBound = MinBound maxBound = MaxBound On Dec 2, 2007 3:25 PM, Ross Paterson wrote: > On Sun, Dec 02, 2007 at 09:57:50AM -0800, Conal Elliott wrote: > > My proposed addition: > > > > -- | Ordered monoid under 'max'. > > newtype Max a = Max { getMax :: a } > > deriving (Eq, Ord, Read, Show, Bounded) > > > > instance (Ord a, Bounded a) => Monoid (Max a) where > > mempty = Max minBound > > Max a `mappend` Max b = Max (a `max` b) > > Funny, I was thinking of proposing a Max type that adjoined a synthetic > identity, as we did in the finger tree paper: > > data Max a = NoMax | Max a > deriving (Eq, Ord, Read, Show) > > instance Ord a => Monoid (Max a) where > mempty = NoMax > NoMax `mappend` b = b > a `mappend` NoMax = a > Max x `mappend` Max y = Max (x `max` y) > > and similarly for Min. One could even define > > getMax :: Bounded a => Max a -> a > getMax NoMax = minBound > getMax (Max x) = x > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20071203/3241aa54/attachment.htm From dons at galois.com Mon Dec 3 15:55:07 2007 From: dons at galois.com (Don Stewart) Date: Mon Dec 3 15:51:04 2007 Subject: QuickCheck properties for IntSet In-Reply-To: References: <20071203051304.GK13662@scytale.galois.com> Message-ID: <20071203205507.GB22650@scytale.galois.com> dbenbenn: > On 12/2/07, Don Stewart wrote: > > Have you tried getting some code coverage for you testsuite, btw? > > (Compile with -fhpc, and then run "hpc report" on the resulting .tix > > file, to get numbers on how thorough the coverage is) > > Thanks for the suggestion! Here's what I get: > > 89% expressions used (1973/2214) > 62% boolean coverage (69/110) > 60% guards (62/103), 35 always True, 6 unevaluated > 100% 'if' conditions (7/7) > 100% qualifiers (0/0) > 87% alternatives used (183/209) > 96% local declarations used (26/27) > 84% top-level declarations used (144/171) > > Next weekend I'll work on pushing these percentages up. > > I wish I could use QuickCheck to write an actual unit test: that is, > an executable program that returns 0 on success, and non-zero on > failure. Then we could put these properties in the tests/ directory, > and have them automatically executed. Is anyone working on such a > feature for QuickCheck? The 'quickCheck' function does this, iirc. -- Don From dbenbenn at gmail.com Mon Dec 3 16:12:35 2007 From: dbenbenn at gmail.com (David Benbennick) Date: Mon Dec 3 16:08:10 2007 Subject: QuickCheck properties for IntSet In-Reply-To: <20071203205507.GB22650@scytale.galois.com> References: <20071203051304.GK13662@scytale.galois.com> <20071203205507.GB22650@scytale.galois.com> Message-ID: On 12/3/07, Don Stewart wrote: > > I wish I could use QuickCheck to write an actual unit test: that is, > > an executable program that returns 0 on success, and non-zero on > > failure. Then we could put these properties in the tests/ directory, > > and have them automatically executed. Is anyone working on such a > > feature for QuickCheck? > > The 'quickCheck' function does this, iirc. I don't think so. I do: > cat foo.hs import Test.QuickCheck main = quickCheck False > runhaskell foo.hs Falsifiable, after 0 tests: > echo $? 0 As far as I can see, quickCheck never causes an error exit to happen. And it doesn't even return IO Bool, so I can't use quickCheck to write my own function that calls System.Exit.exitFailure From dons at galois.com Mon Dec 3 16:18:05 2007 From: dons at galois.com (Don Stewart) Date: Mon Dec 3 16:14:12 2007 Subject: QuickCheck properties for IntSet In-Reply-To: References: <20071203051304.GK13662@scytale.galois.com> <20071203205507.GB22650@scytale.galois.com> Message-ID: <20071203211805.GC22650@scytale.galois.com> dbenbenn: > On 12/3/07, Don Stewart wrote: > > > I wish I could use QuickCheck to write an actual unit test: that is, > > > an executable program that returns 0 on success, and non-zero on > > > failure. Then we could put these properties in the tests/ directory, > > > and have them automatically executed. Is anyone working on such a > > > feature for QuickCheck? > > > > The 'quickCheck' function does this, iirc. > > I don't think so. I do: > > > cat foo.hs > import Test.QuickCheck > main = quickCheck False > > runhaskell foo.hs > Falsifiable, after 0 tests: > > echo $? > 0 > > As far as I can see, quickCheck never causes an error exit to happen. > And it doesn't even return IO Bool, so I can't use quickCheck to write > my own function that calls System.Exit.exitFailure Oh, there's something like this that does actually work in xmonad's tests directory (we use it to have darcs prevent bad patches). Perhaps steal that? -- Don From lemming at henning-thielemann.de Mon Dec 3 16:29:24 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Dec 3 16:25:56 2007 Subject: QuickCheck properties for IntSet In-Reply-To: References: <20071203051304.GK13662@scytale.galois.com> <20071203205507.GB22650@scytale.galois.com> Message-ID: On Mon, 3 Dec 2007, David Benbennick wrote: > On 12/3/07, Don Stewart wrote: > > > I wish I could use QuickCheck to write an actual unit test: that is, > > > an executable program that returns 0 on success, and non-zero on > > > failure. Then we could put these properties in the tests/ directory, > > > and have them automatically executed. Is anyone working on such a > > > feature for QuickCheck? > > > > The 'quickCheck' function does this, iirc. > > I don't think so. I do: > > > cat foo.hs > import Test.QuickCheck > main = quickCheck False > > runhaskell foo.hs > Falsifiable, after 0 tests: > > echo $? > 0 > > As far as I can see, quickCheck never causes an error exit to happen. > And it doesn't even return IO Bool, so I can't use quickCheck to write > my own function that calls System.Exit.exitFailure This problem was discussed recently: http://www.haskell.org/pipermail/haskell-cafe/2007-November/034811.html From dbenbenn at gmail.com Mon Dec 3 16:58:04 2007 From: dbenbenn at gmail.com (David Benbennick) Date: Mon Dec 3 16:53:40 2007 Subject: QuickCheck properties for IntSet In-Reply-To: References: <20071203051304.GK13662@scytale.galois.com> <20071203205507.GB22650@scytale.galois.com> Message-ID: On 12/3/07, Henning Thielemann wrote: > > And it doesn't even return IO Bool, so I can't use quickCheck to write > > my own function that calls System.Exit.exitFailure > > This problem was discussed recently: > http://www.haskell.org/pipermail/haskell-cafe/2007-November/034811.html Yes, quickCheck' from QuickCheck 2 (http://darcs.haskell.org/QuickCheck/Test/QuickCheck/Test.hs) would do the trick. Are there any plans to upgrade Test.QuickCheck to version 2 in GHC? From conal at conal.net Mon Dec 3 18:33:55 2007 From: conal at conal.net (Conal Elliott) Date: Mon Dec 3 18:29:38 2007 Subject: Bounded and floating types In-Reply-To: References: Message-ID: I'm using the bounds for event occurrence times. Or, from another angle, for times associated with when values can become known. Pure values have time minBound, while eternally unknowable values (non-occurring events) have time maxBound. Hm. Now that I put it that way, I realize that I don't want to use existing minBound and maxBound if they're finite. (My event types are temporally polymorphic.) I'm mainly interested in Float/Double times, which have infinities in practice but apparently not guaranteed by the language standard. I guess I'll either (a) bake in Double (temporally monomorphic) and rely on infinities not guaranteed by the standard, or (b) keep temporal polymorphism and add infinities to time parameter. For now, (b). Cheers, - Conal On Dec 2, 2007 1:08 PM, Henning Thielemann < lemming@henning-thielemann.de> wrote: > > On Sun, 2 Dec 2007, Conal Elliott wrote: > > > Oops -- I'd incorrectly assumed that Haskell guarantees Float & Double > to > > have infinities. Thanks, - Conal > > Aside from that - what do you intend to do with the bounds? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20071203/15719f00/attachment-0001.htm From ross at soi.city.ac.uk Mon Dec 3 19:36:38 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Dec 3 19:32:14 2007 Subject: Proposal: add "writer" Monad instance (,) o (Ticket #1951) In-Reply-To: References: Message-ID: <20071204003638.GA11351@soi.city.ac.uk> On Sun, Dec 02, 2007 at 09:27:06AM -0800, Conal Elliott wrote: > I'd like to have a (,)-style writer instance alongside the (->)-based reader > instance for Monad in Control.Monad.Instances. Might as well, as there is already a matching Applicative instance. Control.Monad.Instances is the right place to put the Monad instance, to avoid breaking H98 compatibility. (I'm not sure the Control.Applicative dependency is worth it, but that's an internal detail.) From ross at soi.city.ac.uk Mon Dec 3 20:34:15 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Dec 3 20:30:05 2007 Subject: Proposal: Bounded instance for IntSet (ticket #1953) In-Reply-To: <2608b8a80712030532l4569b020t6233851dd7bf3df5@mail.gmail.com> References: <20071202235336.GA20802@soi.city.ac.uk> <20071203051012.14459.qmail@schroeder.cas.mcmaster.ca> <2608b8a80712030404pb890581qabb261df4717b789@mail.gmail.com> <2608b8a80712030532l4569b020t6233851dd7bf3df5@mail.gmail.com> Message-ID: <20071204013415.GA12261@soi.city.ac.uk> On Mon, Dec 03, 2007 at 03:32:52PM +0200, Yitzchak Gale wrote: > Henning Thielemann wrote: > > ...it is not sensible to have different instances for the same > > type and class, because they will collide sooner or later. > > True. That is why libraries should not define an instance > at all, unless they are quite certain that it is by far the most > important instance that anyone will ever want to use. I would draw the opposite conclusion from the same data: if a sensible instance can be identified, it should accompany either the class or the type constructor. If people define orphan instances, they will eventually collide, even they are identical. (There are a few orphans in Control.Monad.Instances, but that is required to preserve compatibility with Haskell 98.) But in the case at issue, the proposed Bounded instance is counter-intuitive because the underlying Ord instance is. That Ord instance is an arbitrary choice that is accepted because it allows IntSets to be used as search keys; it makes no sense on its own. A Bounded instance would attach unwarranted significance to this arbitrary ordering. It might be different if there were a use in sight for the Bounded instance. From dbenbenn at gmail.com Mon Dec 3 20:56:50 2007 From: dbenbenn at gmail.com (David Benbennick) Date: Mon Dec 3 20:52:25 2007 Subject: Proposal: Bounded instance for IntSet (ticket #1953) In-Reply-To: <20071204013415.GA12261@soi.city.ac.uk> References: <20071202235336.GA20802@soi.city.ac.uk> <20071203051012.14459.qmail@schroeder.cas.mcmaster.ca> <2608b8a80712030404pb890581qabb261df4717b789@mail.gmail.com> <2608b8a80712030532l4569b020t6233851dd7bf3df5@mail.gmail.com> <20071204013415.GA12261@soi.city.ac.uk> Message-ID: On 12/3/07, Ross Paterson wrote: > But in the case at issue, the proposed Bounded instance is > counter-intuitive because the underlying Ord instance is. That Ord > instance is an arbitrary choice that is accepted because it allows IntSets > to be used as search keys; it makes no sense on its own. I don't find that to be the case. If you had asked me to independently come up with an ordering on IntSets, the existing ordering is exactly what I would have invented. As I said earlier, lexicographic order is very well known. It's arbitrary, but it's a universally-agreed arbitrary. It's how words are ordered in paper dictionaries, for example. (To be precise, to compare two IntSets, you convert them to lists with toList, then compare the lists with lexicographic order.) From kahl at cas.mcmaster.ca Mon Dec 3 21:21:11 2007 From: kahl at cas.mcmaster.ca (kahl@cas.mcmaster.ca) Date: Mon Dec 3 21:20:18 2007 Subject: Bounded and floating types In-Reply-To: (conal@conal.net) References: Message-ID: <20071204022111.25798.qmail@schroeder.cas.mcmaster.ca> Conal Elliott wrote: > Pure values have > time minBound, while eternally unknowable values (non-occurring events) have > time maxBound. Hm. Now that I put it that way, I realize that I don't want > to use existing minBound and maxBound if they're finite. (My event types > are temporally polymorphic.) I'm mainly interested in Float/Double times, > which have infinities in practice but apparently not guaranteed by the > language standard. And even in the current implementation with infinities, maxBound would be NaN, not +Inf: Prelude> let z = 0 :: Double Prelude> 0 / z NaN Prelude> 1 / z Infinity Prelude> (-1) / z -Infinity Prelude> (0 / z) `compare` (1 / z) GT Prelude> (0 / z) `compare` ((-1) / z) GT This is another case where the linear ordering provided by Ord has an arbitrary flavour, since the type of IEEE doubles does not have a ``natural'' linear ordering. (And I consider this as independent of whether the IEEE standard prescribes this ordering or not.) For Conal it is probably going to be the question whether he identifies a different interface as serving his purposes better (supported by ``I don't want to use existing minBound and maxBound if they're finite'' and ``For now, (b)'') or whether he thinks that Bounded ``feels right'' for his purposes, and does a newtype for Double without NaN, with the infinities as bounds. My arguments consistently assume the following specification: \begin{spec} forall a . (Ord a, Bounded a) => forall x :: a . minBound <= x && x <= maxBound \end{spec} (I.e., if a type has both Ord and Bounded instances, then for all |x| of that type, |minBound <= x| and |x <= maxBound| are |True| if defined. Normally one would expect, as part of the specification of Ord, that |x <= y| is defined at least when both |x| and |y| are fully defined, i.e., do not contain |undefined| anywhere. So I would not accept |(Nan <= Infinity) = undefined|, but would insist on mapping Nan itself to undefined. ) Yitzchak Gale pointed out: > Where are these axioms? I only see the Haddocks in the Prelude: > > "Ord is not a superclass of Bounded since types that are not > totally ordered may also have upper and lower bounds." This does not contradict my specification, but also does not imply it, although it could be argued that the sentence | The Bounded class is used to name the upper and lower limits of a type. might be understood to imply it --- supported by the discussion. I think the absence of such a specification would be very bad practice, since it relegates Bounded to just provide two arbitrary elements about which nothing can be assumed by any library function. (And I would prefer to have Ord as superclass of Bounded.) While we are looking at the Prelude --- it also has the following: | For any type that is an instance of class Bounded as well as Enum, the | following should hold: | | * The calls succ maxBound and pred minBound should result in a runtime | error. | * fromEnum and toEnum should give a runtime error if the result value is | not representable in the result type. For example, toEnum 7 :: Bool is | an error. | * enumFrom and enumFromThen should be defined with an implicit bound, | thus: | | enumFrom x = enumFromTo x maxBound | enumFromThen x y = enumFromThenTo x y bound | where | bound | fromEnum y >= fromEnum x = maxBound | | otherwise = minBound However, GHC-6.6.1 says: Prelude> succ (1/z) Infinity Prelude> succ (0/z) NaN Prelude> succ ((-1)/z) -Infinity Prelude> pred ((-1)/z) -Infinity So Double cannot be an instance of Bounded... (Aside: Notice: Prelude> succ (maxBound :: Int) *** Exception: Prelude.Enum.succ{Int}: tried to take `succ' of maxBound Prelude> 1 + (maxBound :: Int) -2147483648 so don't use (1 +) unless you want wrap-around. ) And don't use succ, pred, fromEnum, and toEnum unless you are prepared to have run-time errors --- the specification of these run-time errors does not even require an Eq instance, so there is no general way to catch or prevent these. I think a MonadError-based interface would be much better (I also believe that |fail| should not be a member of the class Monad). (I also agree with the Indexable argument, but consider that issue as separate.) Wolfram From stefanor at cox.net Mon Dec 3 22:08:35 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Mon Dec 3 22:04:12 2007 Subject: Proposal: Bounded instance for IntSet (ticket #1953) In-Reply-To: References: <20071202235336.GA20802@soi.city.ac.uk> <20071203051012.14459.qmail@schroeder.cas.mcmaster.ca> <2608b8a80712030404pb890581qabb261df4717b789@mail.gmail.com> <2608b8a80712030532l4569b020t6233851dd7bf3df5@mail.gmail.com> <20071204013415.GA12261@soi.city.ac.uk> Message-ID: <20071204030835.GA3633@localhost.localdomain> On Mon, Dec 03, 2007 at 05:56:50PM -0800, David Benbennick wrote: > On 12/3/07, Ross Paterson wrote: > > But in the case at issue, the proposed Bounded instance is > > counter-intuitive because the underlying Ord instance is. That Ord > > instance is an arbitrary choice that is accepted because it allows IntSets > > to be used as search keys; it makes no sense on its own. > > I don't find that to be the case. If you had asked me to > independently come up with an ordering on IntSets, the existing > ordering is exactly what I would have invented. As I said earlier, > lexicographic order is very well known. It's arbitrary, but it's a > universally-agreed arbitrary. It's how words are ordered in paper > dictionaries, for example. > > (To be precise, to compare two IntSets, you convert them to lists with > toList, then compare the lists with lexicographic order.) I would have used descending order; so it's not *completely* universal. Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/libraries/attachments/20071203/8cd9b32b/attachment.bin From stefanor at cox.net Mon Dec 3 22:18:42 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Mon Dec 3 22:14:19 2007 Subject: Bounded and floating types In-Reply-To: <20071204022111.25798.qmail@schroeder.cas.mcmaster.ca> References: <20071204022111.25798.qmail@schroeder.cas.mcmaster.ca> Message-ID: <20071204031842.GD3633@localhost.localdomain> On Tue, Dec 04, 2007 at 02:21:11AM -0000, kahl@cas.mcmaster.ca wrote: > Conal Elliott wrote: > > > Pure values have > > time minBound, while eternally unknowable values (non-occurring events) have > > time maxBound. Hm. Now that I put it that way, I realize that I don't want > > to use existing minBound and maxBound if they're finite. (My event types > > are temporally polymorphic.) I'm mainly interested in Float/Double times, > > which have infinities in practice but apparently not guaranteed by the > > language standard. > > And even in the current implementation with infinities, > maxBound would be NaN, not +Inf: > > Prelude> let z = 0 :: Double > Prelude> 0 / z > NaN > Prelude> 1 / z > Infinity > Prelude> (-1) / z > -Infinity > Prelude> (0 / z) `compare` (1 / z) > GT > Prelude> (0 / z) `compare` ((-1) / z) > GT > > This is another case where the linear ordering provided by Ord > has an arbitrary flavour, since the type of IEEE doubles > does not have a ``natural'' linear ordering. > (And I consider this as independent of > whether the IEEE standard prescribes this ordering or not.) It's rather worse than that. Prelude> let nan = 0/0 Prelude> nan > nan False Prelude> nan < nan False Prelude> nan == nan False Double isn't even totally ordered! Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/libraries/attachments/20071203/b84de8de/attachment.bin From dbenbenn at gmail.com Mon Dec 3 23:02:17 2007 From: dbenbenn at gmail.com (David Benbennick) Date: Mon Dec 3 22:57:53 2007 Subject: Proposal: Bounded instance for IntSet (ticket #1953) In-Reply-To: <20071204030835.GA3633@localhost.localdomain> References: <20071202235336.GA20802@soi.city.ac.uk> <20071203051012.14459.qmail@schroeder.cas.mcmaster.ca> <2608b8a80712030404pb890581qabb261df4717b789@mail.gmail.com> <2608b8a80712030532l4569b020t6233851dd7bf3df5@mail.gmail.com> <20071204013415.GA12261@soi.city.ac.uk> <20071204030835.GA3633@localhost.localdomain> Message-ID: On 12/3/07, Stefan O'Rear wrote: > I would have used descending order; so it's not *completely* universal. Well, using ascending order agrees with "show" and "toList". But you do have a point. If Ord used descending order, then (isSubsetOf a b) would imply (a <= b). With the existing Ord instance, (isSubsetOf a b) implies nothing about (compare a b). From lemming at henning-thielemann.de Tue Dec 4 07:46:47 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Dec 4 07:42:20 2007 Subject: Bounded and floating types In-Reply-To: References: Message-ID: On Mon, 3 Dec 2007, Conal Elliott wrote: > I'm using the bounds for event occurrence times. Or, from another angle, > for times associated with when values can become known. Pure values have > time minBound, while eternally unknowable values (non-occurring events) have > time maxBound. Hm. Now that I put it that way, I realize that I don't want > to use existing minBound and maxBound if they're finite. (My event types > are temporally polymorphic.) I'm mainly interested in Float/Double times, > which have infinities in practice but apparently not guaranteed by the > language standard. I guess I'll either (a) bake in Double (temporally > monomorphic) and rely on infinities not guaranteed by the standard, or (b) > keep temporal polymorphism and add infinities to time parameter. For now, > (b). Since you cannot rely on the existence of an infinity value for a floating point type with a particular behaviour - you can simply define you own type: data InfinityClosure a = NegativeInfinity | Finite a | PositiveInfinity From ahey at iee.org Tue Dec 4 12:11:08 2007 From: ahey at iee.org (Adrian Hey) Date: Tue Dec 4 12:06:42 2007 Subject: Maybe Monoid spilt milk In-Reply-To: <20071129183726.GC2090@scytale.galois.com> References: <55976F24-1ACA-4C3D-ABE1-F64288FE3D4C@Cs.Nott.AC.UK> <20071129183726.GC2090@scytale.galois.com> Message-ID: <47558A2C.20501@iee.org> Don Stewart wrote: > The Monoid instance is not that widely used -- I think it is not too > late to change. If this sort of thing is fixable retrospectively then maybe the Monoid instance for Data.Map should be fixed too.. http://hackage.haskell.org/trac/ghc/ticket/1460 ..assuming there's general agreement that the current instance is broken. The latter definition is what's used in the "clone" I wrote BTW, so they're incompatible at the moment as far as this is concerned. Regards -- Adrian Hey From conal at conal.net Tue Dec 4 15:45:43 2007 From: conal at conal.net (Conal Elliott) Date: Tue Dec 4 15:41:18 2007 Subject: Bounded and floating types In-Reply-To: References: Message-ID: Thanks. That's exactly what I've done: -- | Wrap a type into one having new least and greatest elements, -- preserving the existing ordering. data AddBounds a = MinBound | NoBound a | MaxBound deriving (Eq, Ord, Read, Show) instance Bounded (AddBounds a) where minBound = MinBound maxBound = MaxBound Looks like a generally useful tool. Is there any interest in seeing it added to a standard lib? - Conal On Dec 4, 2007 4:46 AM, Henning Thielemann wrote: > > On Mon, 3 Dec 2007, Conal Elliott wrote: > > > I'm using the bounds for event occurrence times. Or, from another > angle, > > for times associated with when values can become known. Pure values > have > > time minBound, while eternally unknowable values (non-occurring events) > have > > time maxBound. Hm. Now that I put it that way, I realize that I don't > want > > to use existing minBound and maxBound if they're finite. (My event > types > > are temporally polymorphic.) I'm mainly interested in Float/Double > times, > > which have infinities in practice but apparently not guaranteed by the > > language standard. I guess I'll either (a) bake in Double (temporally > > monomorphic) and rely on infinities not guaranteed by the standard, or > (b) > > keep temporal polymorphism and add infinities to time parameter. For > now, > > (b). > > Since you cannot rely on the existence of an infinity value for a floating > point type with a particular behaviour - you can simply define you own > type: > > data InfinityClosure a = NegativeInfinity | Finite a | PositiveInfinity > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20071204/c95d14e9/attachment.htm From alistair at abayley.org Tue Dec 4 16:42:21 2007 From: alistair at abayley.org (Alistair Bayley) Date: Tue Dec 4 16:37:54 2007 Subject: GHC's CPP and Cabal's unlit In-Reply-To: <79d7c4980711290554g1abbac6bh934d0c6e4781a829@mail.gmail.com> References: <79d7c4980711280259n4240545v62dbd78ca47511d3@mail.gmail.com> <79d7c4980711281437q95fa804h66d992709a349b@mail.gmail.com> <1196332390.21580.25.camel@localhost> <79d7c4980711290318w1f13e442g33c7c4b0ef14a514@mail.gmail.com> <1196338485.21580.41.camel@localhost> <125EACD0CAE4D24ABDB4D148C4593DA9049E915A@GBLONXMB02.corp.amvescap.net> <1196343469.21580.77.camel@localhost> <79d7c4980711290554g1abbac6bh934d0c6e4781a829@mail.gmail.com> Message-ID: <79d7c4980712041342t664410b2k12a8d2aef0d50a0c@mail.gmail.com> > > It would be nice if we can find an unlit extension that is compatible > > with the H98 requirement and alo allows useful behaviour for haddock. I have completed changes to the Unlit module, and also a change to the Haddock module (to run unlit before cpp). darcs patches attached. I'd love to know what the official approach to testing is. I have written a test module which exercises the Unlit module, but I'm not sure how to tie it in to any existing test infrastructure. At the moment I just have it sitting in tests/unlit. Thanks, Alistair -------------- next part -------------- A non-text attachment was scrubbed... Name: haddock_unlit.patch Type: application/octet-stream Size: 20882 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20071204/aaeeba62/haddock_unlit-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: unlit_preserve_comments.patch Type: application/octet-stream Size: 26739 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20071204/aaeeba62/unlit_preserve_comments-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UnlitTest.hs Type: application/octet-stream Size: 2759 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20071204/aaeeba62/UnlitTest-0001.obj From wnoise at ofb.net Tue Dec 4 19:24:52 2007 From: wnoise at ofb.net (Aaron Denney) Date: Tue Dec 4 19:20:42 2007 Subject: Proposal: Bounded instance for IntSet (ticket #1953) References: <20071202235336.GA20802@soi.city.ac.uk> <20071203051012.14459.qmail@schroeder.cas.mcmaster.ca> <2608b8a80712030404pb890581qabb261df4717b789@mail.gmail.com> <2608b8a80712030532l4569b020t6233851dd7bf3df5@mail.gmail.com> <20071204013415.GA12261@soi.city.ac.uk> Message-ID: On 2007-12-04, Ross Paterson wrote: > On Mon, Dec 03, 2007 at 03:32:52PM +0200, Yitzchak Gale wrote: >> Henning Thielemann wrote: >> > ...it is not sensible to have different instances for the same >> > type and class, because they will collide sooner or later. >> >> True. That is why libraries should not define an instance >> at all, unless they are quite certain that it is by far the most >> important instance that anyone will ever want to use. > > I would draw the opposite conclusion from the same data: if a sensible > instance can be identified, it should accompany either the class or > the type constructor. If people define orphan instances, they will > eventually collide, even they are identical. (There are a few orphans in > Control.Monad.Instances, but that is required to preserve compatibility > with Haskell 98.) I strongly concur. -- Aaron Denney -><- From ketil+haskell at ii.uib.no Wed Dec 5 03:18:38 2007 From: ketil+haskell at ii.uib.no (Ketil Malde) Date: Wed Dec 5 03:14:11 2007 Subject: Bounded and floating types In-Reply-To: <20071204031842.GD3633@localhost.localdomain> (Stefan O'Rear's message of "Mon\, 3 Dec 2007 19\:18\:42 -0800") References: <20071204022111.25798.qmail@schroeder.cas.mcmaster.ca> <20071204031842.GD3633@localhost.localdomain> Message-ID: <873auha71d.fsf@nmd9999.imr.no> Stefan O'Rear writes: > It's rather worse than that. > > Prelude> let nan = 0/0 > Prelude> nan > nan > False > Prelude> nan < nan > False > Prelude> nan == nan > False And this begs the question: Prelude> compare nan nan GT So while NaN is greater than itself, it is at the same time not greater than itself? -k -- If I haven't seen further, it is by standing in the footprints of giants From gale at sefer.org Wed Dec 5 05:10:10 2007 From: gale at sefer.org (Yitzchak Gale) Date: Wed Dec 5 05:05:41 2007 Subject: Bounded and floating types In-Reply-To: <20071204022111.25798.qmail@schroeder.cas.mcmaster.ca> References: <20071204022111.25798.qmail@schroeder.cas.mcmaster.ca> Message-ID: <2608b8a80712050210w349668f1na482423e7727a710@mail.gmail.com> Wolfram wrote: > My arguments consistently assume the following specification: > \begin{spec} > forall a . (Ord a, Bounded a) => > forall x :: a . minBound <= x && x <= maxBound > \end{spec} That sounds like a great thing to suggest for Haskell'. It is not true currently. Ord and Bounded are independent of each other. Current discussions on this list make it clear that forcibly enforcing such a restriction, e.g. by introducing Bounded instances in libraries, would break people's existing programs. Your restriction implies, among other things, that Ord may only be used for natural universal orderings of a type, not for arbitrary artificial orderings introduced for technical reasons. Because otherwise, why restrict people from using a natural Bounded instance if there is one, or a Bounded instance that is needed for some other technical reason? A good migration path towards your idea would be to fix the current most prominent offenders, the Data. modules, by providing an additional version of each that uses Indexable instead of Ord for artificial orderings, as suggest by Henning. And, of course, there is nothing to stop us from suggesting that people adhere to your specification by adding it to the documentation. I wrote: >> Where are these axioms? > ...it could be argued that the sentence: "The Bounded class > is used to name the upper and lower limits of a type." > might be understood to imply it Given the current usage of Ord in the libraries, there is no reason to think that the upper and lower limits *of a type* necessarily have anything to do with Ord. -Yitz From lemming at henning-thielemann.de Wed Dec 5 09:40:45 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Dec 5 09:36:16 2007 Subject: System.Random: enumRandomR, boundedEnumRandom Message-ID: Did you also already need Random instances of enumerations? Wouldn't it be nice to have some helper functions in System.Random: enumRandomR :: (Enum a, RandomGen g) => (a,a) -> g -> (a,g) enumRandomR (l,r) = mapFst toEnum . randomR (fromEnum l, fromEnum r) boundedEnumRandom :: (Enum a, Bounded a, RandomGen g) => g -> (a,g) boundedEnumRandom = enumRandomR (minBound, maxBound) mapFst :: (a -> c) -> (a,b) -> (c,b) mapFst f ~(x,y) = (f x, y) Example application: instance Random Day where random = boundedEnumRandom randomR = enumRandomR From stefanor at cox.net Wed Dec 5 20:44:36 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Wed Dec 5 20:40:05 2007 Subject: Bounded and floating types In-Reply-To: <873auha71d.fsf@nmd9999.imr.no> References: <20071204022111.25798.qmail@schroeder.cas.mcmaster.ca> <20071204031842.GD3633@localhost.localdomain> <873auha71d.fsf@nmd9999.imr.no> Message-ID: <20071206014435.GA3975@localhost.localdomain> On Wed, Dec 05, 2007 at 09:18:38AM +0100, Ketil Malde wrote: > Stefan O'Rear writes: > > > It's rather worse than that. > > > > Prelude> let nan = 0/0 > > Prelude> nan > nan > > False > > Prelude> nan < nan > > False > > Prelude> nan == nan > > False > > And this begs the question: > > Prelude> compare nan nan > GT > > So while NaN is greater than itself, it is at the same time not > greater than itself? There is a case to be made for Ord Double to use the trapping comparison operators. Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/libraries/attachments/20071205/d63b9d16/attachment.bin From peteg42 at gmail.com Thu Dec 6 05:35:48 2007 From: peteg42 at gmail.com (Peter Gammie) Date: Thu Dec 6 05:31:20 2007 Subject: Cabal, System.Filepath Message-ID: <392A88B6-1247-460E-9FFF-70AA938389C0@gmail.com> To my surprise, if you type ^C at the right moment you can trash GHC's (system-wide) package list. I figured it was easier to reinstall than fix, but forgot Debian installs GHC 6.6 if I don't ask for "unstable". So, let's get Cabal on its feet again: $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.6 $ darcs pull Pulling from "http://darcs.haskell.org/cabal"... No remote changes to pull in! $ ghc -i. --make Setup.lhs -o setup Distribution/Simple.hs:114:7: Could not find module `System.FilePath': Use -v to see a list of the files searched for. Can I humbly suggest that Cabal rely on very few external libraries? (I'm switching to 6.6.1 as I type this.) cheers peter From duncan.coutts at worc.ox.ac.uk Thu Dec 6 06:56:41 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Dec 6 06:54:35 2007 Subject: Cabal, System.Filepath In-Reply-To: <392A88B6-1247-460E-9FFF-70AA938389C0@gmail.com> References: <392A88B6-1247-460E-9FFF-70AA938389C0@gmail.com> Message-ID: <1196942201.22469.19.camel@localhost> On Thu, 2007-12-06 at 17:35 +0700, Peter Gammie wrote: > To my surprise, if you type ^C at the right moment you can trash GHC's > (system-wide) package list. I figured it was easier to reinstall than > fix, but forgot Debian installs GHC 6.6 if I don't ask for "unstable". > So, let's get Cabal on its feet again: Debian actually installs a backup of the global package.conf file. It's called package.conf.shipped or something like that. > $ ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.6 > > $ darcs pull > Pulling from "http://darcs.haskell.org/cabal"... > No remote changes to pull in! > > $ ghc -i. --make Setup.lhs -o setup > > Distribution/Simple.hs:114:7: > Could not find module `System.FilePath': > Use -v to see a list of the files searched for. > > Can I humbly suggest that Cabal rely on very few external libraries? We recently defined filepath to be a core library. As you point out however this does pose a problem for older compilers. Fortunately it's not that bad, you can build and install filepath using the older cabal that comes with your older compiler. If that's not possible for whatever reason you can download both Cabal and filepath and: ghc -i../filepath --make Setup.lhs -o setup Duncan From peteg42 at gmail.com Thu Dec 6 09:44:55 2007 From: peteg42 at gmail.com (Peter Gammie) Date: Thu Dec 6 09:40:32 2007 Subject: Cabal, System.Filepath In-Reply-To: <1196942201.22469.19.camel@localhost> References: <392A88B6-1247-460E-9FFF-70AA938389C0@gmail.com> <1196942201.22469.19.camel@localhost> Message-ID: On 06/12/2007, at 6:56 PM, Duncan Coutts wrote: > On Thu, 2007-12-06 at 17:35 +0700, Peter Gammie wrote: >> Can I humbly suggest that Cabal rely on very few external libraries? > > We recently defined filepath to be a core library. As you point out > however this does pose a problem for older compilers. Fortunately it's > not that bad, you can build and install filepath using the older cabal > that comes with your older compiler. If that's not possible for > whatever > reason you can download both Cabal and filepath and: > > ghc -i../filepath --make Setup.lhs -o setup I realise all this, I just wanted to log the fact that darcs-Cabal does not build on GHC 6.6. I thought it was a design goal for Cabal to compile on all GHCs back to 6.4.x (or something). No matter, I installed GHC 6.6.1: $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.6.1 Next problem: let's reinstall the 'cgi' package (latest from darcs): $ ghc-pkg list /usr/lib/ghc-6.6.1/package.conf: Cabal-1.1.6.2, Cabal-1.3.1, base-2.1.1, filepath-1.0, (ghc-6.6.1), haskell98-1.0, parsec-2.0, readline-1.0, regex-base-0.72, regex-compat-0.71, regex-posix-0.71, rts-1.0, stm-2.0, template-haskell-2.1, unix-2.1 /home/peteg/.ghc/i386-linux-6.6.1/package.conf: mtl-1.1.0.0, network-2.1.0.0, xhtml-3000.0.2.1 Note that I've installed the dependencies in my home directory. $ runghc Setup.*hs configure --prefix=$HOME -v3 Configuring cgi-3001.1.5.1... Creating dist (and its parents) /usr/bin/ghc --numeric-version looking for package tool: ghc-pkg near compiler in /usr/bin found package tool in /usr/bin/ghc-pkg /usr/bin/ghc-pkg --version /usr/bin/ghc -c /tmp/tmp19799.c -o /tmp/tmp19799.o /usr/bin/ld -x -r /tmp/tmp19799.o -o /tmp/tmp19800.o Reading installed packages... /usr/bin/ghc-pkg --global list Setup.hs: At least the following dependencies are missing: network >=2.0, mtl >=1.0, xhtml >=3000.0.0 Why is ghc-pkg looking only at globally-installed packages? cheers peter From vigalchin at gmail.com Thu Dec 6 17:14:01 2007 From: vigalchin at gmail.com (Galchin Vasili) Date: Thu Dec 6 17:09:29 2007 Subject: who are the contributors to the Unix package? Message-ID: <5ae4f2ba0712061414n19dab390tff384ba41badcb6@mail.gmail.com> Hello, Who started this effort? Who is currently doing work on the Unix package? Kind regards, Vasya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20071206/a1dbaaab/attachment-0001.htm From dons at galois.com Thu Dec 6 17:15:26 2007 From: dons at galois.com (Don Stewart) Date: Thu Dec 6 17:11:04 2007 Subject: who are the contributors to the Unix package? In-Reply-To: <5ae4f2ba0712061414n19dab390tff384ba41badcb6@mail.gmail.com> References: <5ae4f2ba0712061414n19dab390tff384ba41badcb6@mail.gmail.com> Message-ID: <20071206221526.GC30271@scytale.galois.com> vigalchin: > Hello, > > Who started this effort? Who is currently doing work on the Unix > package? > > Kind regards, Vasya It is maintained by libraries@haskell.org From duncan.coutts at worc.ox.ac.uk Thu Dec 6 17:40:31 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Dec 6 17:35:47 2007 Subject: Cabal, System.Filepath In-Reply-To: References: <392A88B6-1247-460E-9FFF-70AA938389C0@gmail.com> <1196942201.22469.19.camel@localhost> Message-ID: <1196980831.22469.25.camel@localhost> On Thu, 2007-12-06 at 21:44 +0700, Peter Gammie wrote: > On 06/12/2007, at 6:56 PM, Duncan Coutts wrote: > > > On Thu, 2007-12-06 at 17:35 +0700, Peter Gammie wrote: > >> Can I humbly suggest that Cabal rely on very few external libraries? > > > > We recently defined filepath to be a core library. As you point out > > however this does pose a problem for older compilers. Fortunately it's > > not that bad, you can build and install filepath using the older cabal > > that comes with your older compiler. If that's not possible for > > whatever reason you can download both Cabal and filepath and: > > > > ghc -i../filepath --make Setup.lhs -o setup > > I realise all this, I just wanted to log the fact that darcs-Cabal > does not build on GHC 6.6. I thought it was a design goal for Cabal to > compile on all GHCs back to 6.4.x (or something). I have considered bundling filepath for exactly this reason. I'm still undecided. > Why is ghc-pkg looking only at globally-installed packages? It's not ghc-pkg, it's Cabal that by default only looks at the global packages. You can configure with --user to have it look at the user ones. Personally I'm in favour of switching the default to --user. Of course it cannot use user packages and then install globally, and the current default prefix is /usr/local which is usually root only, so if we switch the default to user installs then we'd have to switch the default prefix. I'd prefer that too though. However it's a change that would require general consensus. Duncan From peteg42 at gmail.com Thu Dec 6 19:24:47 2007 From: peteg42 at gmail.com (Peter Gammie) Date: Thu Dec 6 19:20:35 2007 Subject: Cabal, System.Filepath In-Reply-To: <1196980831.22469.25.camel@localhost> References: <392A88B6-1247-460E-9FFF-70AA938389C0@gmail.com> <1196942201.22469.19.camel@localhost> <1196980831.22469.25.camel@localhost> Message-ID: <40B8FCC0-5B80-478E-BC05-F85C24855352@gmail.com> On 07/12/2007, at 5:40 AM, Duncan Coutts wrote: > On Thu, 2007-12-06 at 21:44 +0700, Peter Gammie wrote: >> Why is ghc-pkg looking only at globally-installed packages? > > It's not ghc-pkg, it's Cabal that by default only looks at the global > packages. You can configure with --user to have it look at the user > ones. Personally I'm in favour of switching the default to --user. > > Of course it cannot use user packages and then install globally, and > the > current default prefix is /usr/local which is usually root only, so if > we switch the default to user installs then we'd have to switch the > default prefix. I'd prefer that too though. However it's a change that > would require general consensus. Ah, I see. I didn't realise configure had a --user switch as well. A stop-gap might be to generate a more helpful error message: ghc-pkg --global list if unsatisfied dep ghc-pkg list if dep is satisfied now, print "Perhaps configure with --user?" IMH and not so informed opinion, I think the defaults should be close to autoconf's, if only by the principle of least surprise. Thanks! cheers peter From lemming at henning-thielemann.de Fri Dec 7 03:02:30 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Dec 7 02:58:34 2007 Subject: hierarchical module names Message-ID: From http://haskell.org/haskellwiki/How_to_write_a_Haskell_program#Hierarchical_source there is a link to http://www.haskell.org/~simonmar/lib-hierarchy.html It looks a bit out of date (no Control.Arrow, but DSP instead of Sound). Is there a more current list? From apfelmus at quantentunnel.de Fri Dec 7 05:00:29 2007 From: apfelmus at quantentunnel.de (apfelmus) Date: Fri Dec 7 04:56:15 2007 Subject: mtl documentation - external link broken Message-ID: Hello, In the documentation for the monad transformer library, the hyperlink http://www.cse.ogi.edu/~mpj/ to Mark P. Jones' homepage is broken. It's used to reference his paper Functional Programming with Overloading and Higher-Order Polymorphism The new location is http://web.cecs.pdx.edu/~mpj/ Regards, apfelmus From cdsmith at twu.net Sat Dec 8 01:38:23 2007 From: cdsmith at twu.net (Chris Smith) Date: Sat Dec 8 01:34:03 2007 Subject: Documentation and HAppS Message-ID: I'm making an offer. I need to learn HAppS extremely well over the next couple months. I am willing to document the process by attempting to write detailed documentation on developing applications with HAppS. Something on the order that could be eventually combined into a book, or at least an extensive searchable web site. My current thoughts are to either: 1. Find a free wiki site to do it. 2. Use HaskellWiki 3. Coordinate with Alex regarding the HAppS web site I'm not sure which would be most appropriate. My hope would be to make this public early, since I'm bound to make some mistakes or leave some things out. So I'm sort of counting on getting comments from people who know more than me. Finally, I'm not sure whether code currently in a sufficiently good state that it would be reasonable to write something like this. Perhaps I should hold off and wait for things to stabilize. So: - Is this something people would find helpful? - Should I do it now, or wait? - Which of the choices (1), (2), or (3) above do you think best of? Thanks, -- Chris Smith From cdsmith at twu.net Sat Dec 8 01:39:12 2007 From: cdsmith at twu.net (Chris Smith) Date: Sat Dec 8 01:35:25 2007 Subject: Documentation and HAppS References: Message-ID: Sorry, wrong mailing list! From dbenbenn at gmail.com Sat Dec 8 05:18:31 2007 From: dbenbenn at gmail.com (David Benbennick) Date: Sat Dec 8 05:13:53 2007 Subject: QuickCheck properties for IntSet In-Reply-To: References: <20071203051304.GK13662@scytale.galois.com> <20071203205507.GB22650@scytale.galois.com> Message-ID: Here's an improved version of the patch. It adds 11 more QuickCheck properties. Now everything is tested except: * The Data instance for IntSet (does anyone know how to test that?) * The debugging functions showTree and showTreeWith * The various read functions (read, readList, reads, readsPrec) are not that well tested, especially parse failures. I found that IntSet.showTree and IntSet.showTreeWith are not identical to Set.showTree and Set.showTreeWith. Not a big deal since they're just debugging functions, I guess. But it means I can't include QuickCheck properties for them. I commented out some code that could never be executed: * Some case-statement cases that could never occur. * >>= for the Identity monad used internally. union had an odd comment about "right bias". I under