From twanvl at gmail.com Sun Nov 1 17:00:34 2009 From: twanvl at gmail.com (Twan van Laarhoven) Date: Sun Nov 1 16:36:44 2009 Subject: Data.IntMap/IntSet inconsistencies Message-ID: <4AEE0502.7010905@gmail.com> The interfaces from Data.IntMap and Data.Map are subtly different. Here are two issues: 1. deleteMin/Max raise an exception on empty maps/set > Data.Map.deleteMax Data.Map.empty fromList [] > Data.IntMap.deleteMax Data.IntMap.empty fromList *** Exception: deleteMax: empty map has no maximal element > Data.Set.deleteMin Data.Set.empty fromList [] > Data.IntSet.deleteMin Data.IntSet.empty fromList *** Exception: deleteMin: empty set has no minimal element Proposal: Data.IntMap/IntSet.deleteMin/Max should return empty when the input is empty. 2. findMin/Max have a different signature Data.Map.findMin :: Map k a -> (k, a) Data.IntMap.findMin :: IntMap a -> a The documentation of IntMap.findMin is also incorrect, it reads: /O(log n)/ The minimal key of the map. While it returns the value associated with the minimal key. Proposal: Data.IntMap.findMin/findMax should have the type IntMap a -> (Key,a) Twan From nicolas.pouillard at gmail.com Sun Nov 1 17:42:59 2009 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Sun Nov 1 17:19:15 2009 Subject: Data.IntMap/IntSet inconsistencies In-Reply-To: <4AEE0502.7010905@gmail.com> References: <4AEE0502.7010905@gmail.com> Message-ID: <1257115306-sup-8212@peray> Excerpts from Twan van Laarhoven's message of Sun Nov 01 23:00:34 +0100 2009: > The interfaces from Data.IntMap and Data.Map are subtly different. Here are two > issues: Both issues are real, and both solutions are reasonable. I support them. -- Nicolas Pouillard http://nicolaspouillard.fr From ekmett at gmail.com Mon Nov 2 11:05:06 2009 From: ekmett at gmail.com (Edward Kmett) Date: Mon Nov 2 10:41:19 2009 Subject: Data.IntMap/IntSet inconsistencies In-Reply-To: <4AEE0502.7010905@gmail.com> References: <4AEE0502.7010905@gmail.com> Message-ID: <7fb8f82f0911020805t2d763436r2f7fb17a32751ec4@mail.gmail.com> +1. I'm somewhat leery of the interface change on #2, but I thnk consistency is warranted and the burden of fixing it would only get worse with time. -Edward Kmett On Sun, Nov 1, 2009 at 5:00 PM, Twan van Laarhoven wrote: > The interfaces from Data.IntMap and Data.Map are subtly different. Here are > two issues: > > > 1. deleteMin/Max raise an exception on empty maps/set > > > Data.Map.deleteMax Data.Map.empty > fromList [] > > Data.IntMap.deleteMax Data.IntMap.empty > fromList *** Exception: deleteMax: empty map has no maximal element > > > Data.Set.deleteMin Data.Set.empty > fromList [] > > Data.IntSet.deleteMin Data.IntSet.empty > fromList *** Exception: deleteMin: empty set has no minimal element > > Proposal: Data.IntMap/IntSet.deleteMin/Max should return empty when the > input is empty. > > > 2. findMin/Max have a different signature > > Data.Map.findMin :: Map k a -> (k, a) > Data.IntMap.findMin :: IntMap a -> a > > The documentation of IntMap.findMin is also incorrect, it reads: > > /O(log n)/ The minimal key of the map. > > While it returns the value associated with the minimal key. > > Proposal: Data.IntMap.findMin/findMax should have the type IntMap a -> > (Key,a) > > > > Twan > _______________________________________________ > 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/20091102/15b01382/attachment.html From malcolm.wallace at cs.york.ac.uk Mon Nov 2 12:53:44 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Mon Nov 2 12:29:57 2009 Subject: Data.IntMap/IntSet inconsistencies In-Reply-To: <4AEE0502.7010905@gmail.com> References: <4AEE0502.7010905@gmail.com> Message-ID: On 1 Nov 2009, at 22:00, Twan van Laarhoven wrote: > The interfaces from Data.IntMap and Data.Map are subtly different. > > Proposal: Data.IntMap/IntSet.deleteMin/Max should return empty when > the input is empty. > > Proposal: Data.IntMap.findMin/findMax should have the type IntMap a > -> (Key,a) +1 for consistency. Regards, Malcolm From qdunkan at gmail.com Mon Nov 2 13:14:27 2009 From: qdunkan at gmail.com (Evan Laforge) Date: Mon Nov 2 12:50:41 2009 Subject: Data.IntMap/IntSet inconsistencies In-Reply-To: <4AEE0502.7010905@gmail.com> References: <4AEE0502.7010905@gmail.com> Message-ID: <2518b95d0911021014s793dcd3cv9a597768655b4b2d@mail.gmail.com> Also +1. On a related note, I think it's unfortunate that those functions are partial. Like List.minimum and maximum, I always wind up wrapping them in a function that provides a default value. I suppose that would be a different proposal though... but maybe if we're breaking compatibility anyway it would be a good time to, say, change them to 'IntMap k a -> (k, a) -> (k, a)'? Actually, it seems that often 'IntMap k a -> b -> ((k, a) -> b) -> b' is more convenient, e.g. 'findMax fm Nothing Just', and you can always get the default val version back with 'id'. From igloo at earth.li Mon Nov 2 13:17:01 2009 From: igloo at earth.li (Ian Lynagh) Date: Mon Nov 2 12:53:14 2009 Subject: Data.IntMap/IntSet inconsistencies In-Reply-To: <4AEE0502.7010905@gmail.com> References: <4AEE0502.7010905@gmail.com> Message-ID: <20091102181701.GA24969@matrix.chaos.earth.li> On Sun, Nov 01, 2009 at 11:00:34PM +0100, Twan van Laarhoven wrote: > > 2. findMin/Max have a different signature > > Data.Map.findMin :: Map k a -> (k, a) > Data.IntMap.findMin :: IntMap a -> a This part is already fixed in 6.12/HEAD: Prelude> :t Data.IntMap.findMin Data.IntMap.findMin :: Data.IntMap.IntMap a -> (Int, a) Thanks Ian From aslatter at gmail.com Mon Nov 2 13:23:47 2009 From: aslatter at gmail.com (Antoine Latter) Date: Mon Nov 2 13:00:00 2009 Subject: Data.IntMap/IntSet inconsistencies In-Reply-To: <2518b95d0911021014s793dcd3cv9a597768655b4b2d@mail.gmail.com> References: <4AEE0502.7010905@gmail.com> <2518b95d0911021014s793dcd3cv9a597768655b4b2d@mail.gmail.com> Message-ID: <694519c50911021023sf91e2c3gf7158669eee690a3@mail.gmail.com> On Mon, Nov 2, 2009 at 12:14 PM, Evan Laforge wrote: > Also +1. > > On a related note, I think it's unfortunate that those functions are > partial. ?Like List.minimum and maximum, I always wind up wrapping > them in a function that provides a default value. > > I suppose that would be a different proposal though... but maybe if > we're breaking compatibility anyway it would be a good time to, say, > change them to 'IntMap k a -> (k, a) -> (k, a)'? ?Actually, it seems > that often 'IntMap k a -> b -> ((k, a) -> b) -> b' is more convenient, > e.g. 'findMax fm Nothing Just', and you can always get the default val > version back with 'id'. I would prefer that partial functions return 'Maybe' - then I can pick whether or not I want 'Prelude.maybe' behavior or 'Data.Maybe.fromMaybe' behavior. I would prefer seeing findMax :: Map k a -> Maybe (k, a). It's also easier to read the function signature and know what is going to happen, rather than giving the function three parameters. But it sounds like we need a different ticket. Antoine From ross at soi.city.ac.uk Mon Nov 2 13:36:56 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Nov 2 13:13:11 2009 Subject: Data.IntMap/IntSet inconsistencies In-Reply-To: <4AEE0502.7010905@gmail.com> References: <4AEE0502.7010905@gmail.com> Message-ID: <20091102183656.GA28989@soi.city.ac.uk> On Sun, Nov 01, 2009 at 11:00:34PM +0100, Twan van Laarhoven wrote: > Proposal: Data.IntMap/IntSet.deleteMin/Max should return empty when > the input is empty. Yes, and also for updateMinWithKey and updateMaxWithKey. > Proposal: Data.IntMap.findMin/findMax should have the type IntMap a -> (Key,a) Proposal: deprecate and then remove find, findIndex, findMin, findMax, deleteFindMin and deleteFindMax. From qdunkan at gmail.com Mon Nov 2 15:30:49 2009 From: qdunkan at gmail.com (Evan Laforge) Date: Mon Nov 2 15:07:01 2009 Subject: Data.IntMap/IntSet inconsistencies In-Reply-To: <694519c50911021023sf91e2c3gf7158669eee690a3@mail.gmail.com> References: <4AEE0502.7010905@gmail.com> <2518b95d0911021014s793dcd3cv9a597768655b4b2d@mail.gmail.com> <694519c50911021023sf91e2c3gf7158669eee690a3@mail.gmail.com> Message-ID: <2518b95d0911021230n391015c6m383b1b1f8788e3c0@mail.gmail.com> > I would prefer that partial functions return 'Maybe' - then I can pick > whether or not I want 'Prelude.maybe' behavior or > 'Data.Maybe.fromMaybe' behavior. I would prefer seeing findMax :: Map > k a -> Maybe (k, a). > > It's also easier to read the function signature and know what is going > to happen, rather than giving the function three parameters. Sure, this is reasonable too. [ ross ] > Proposal: deprecate and then remove find, findIndex, findMin, findMax, > deleteFindMin and deleteFindMax. List.find? No thanks, I use that all the time. As far as findMin, toAscList works just as well, so fine, let's kill it. For findMax, toDescList, which I thought was patched in a year ago, still doesn't appear in the latest version of collections, so as far as I know there's no alternative for it. As far as findIndex, are there any known uses for indexed Maps? I haven't used it but maybe there's some important use I don't know about. From ross at soi.city.ac.uk Mon Nov 2 16:57:52 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Nov 2 16:34:08 2009 Subject: Data.IntMap/IntSet inconsistencies In-Reply-To: <2518b95d0911021230n391015c6m383b1b1f8788e3c0@mail.gmail.com> References: <4AEE0502.7010905@gmail.com> <2518b95d0911021014s793dcd3cv9a597768655b4b2d@mail.gmail.com> <694519c50911021023sf91e2c3gf7158669eee690a3@mail.gmail.com> <2518b95d0911021230n391015c6m383b1b1f8788e3c0@mail.gmail.com> Message-ID: <20091102215752.GA27337@soi.city.ac.uk> On Mon, Nov 02, 2009 at 01:30:49PM -0700, Evan Laforge wrote: > [ ross ] > > Proposal: deprecate and then remove find, findIndex, findMin, findMax, > > deleteFindMin and deleteFindMax. > > List.find? No thanks, I use that all the time. No, Data.(Int)Map.find > For findMax, toDescList, which I thought was patched in a year > ago, still doesn't appear in the latest version of collections, so as > far as I know there's no alternative for it. Containers is a core package, so it's tied to GHC's release cycle: one major release per year and only bugfixes between them. From qdunkan at gmail.com Mon Nov 2 18:17:13 2009 From: qdunkan at gmail.com (Evan Laforge) Date: Mon Nov 2 17:53:27 2009 Subject: Data.IntMap/IntSet inconsistencies In-Reply-To: <20091102215752.GA27337@soi.city.ac.uk> References: <4AEE0502.7010905@gmail.com> <2518b95d0911021014s793dcd3cv9a597768655b4b2d@mail.gmail.com> <694519c50911021023sf91e2c3gf7158669eee690a3@mail.gmail.com> <2518b95d0911021230n391015c6m383b1b1f8788e3c0@mail.gmail.com> <20091102215752.GA27337@soi.city.ac.uk> Message-ID: <2518b95d0911021517l48f903a9k1c8ecb5e07d0379e@mail.gmail.com> On Mon, Nov 2, 2009 at 1:57 PM, Ross Paterson wrote: > On Mon, Nov 02, 2009 at 01:30:49PM -0700, Evan Laforge wrote: >> [ ross ] >> > Proposal: deprecate and then remove find, findIndex, findMin, findMax, >> > deleteFindMin and deleteFindMax. >> >> List.find? ?No thanks, I use that all the time. > > No, Data.(Int)Map.find Yeah, I can't find it on http://www.haskell.org/ghc/docs/latest/html/libraries/containers/Data-Map.html. What's the signature? >> For findMax, toDescList, which I thought was patched in a year >> ago, still doesn't appear in the latest version of collections, so as >> far as I know there's no alternative for it. > > Containers is a core package, so it's tied to GHC's release cycle: > one major release per year and only bugfixes between them. I see, yet another reason to look forward to 6.12 :) From ross at soi.city.ac.uk Mon Nov 2 18:21:45 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Nov 2 17:58:00 2009 Subject: Data.IntMap/IntSet inconsistencies In-Reply-To: <2518b95d0911021517l48f903a9k1c8ecb5e07d0379e@mail.gmail.com> References: <4AEE0502.7010905@gmail.com> <2518b95d0911021014s793dcd3cv9a597768655b4b2d@mail.gmail.com> <694519c50911021023sf91e2c3gf7158669eee690a3@mail.gmail.com> <2518b95d0911021230n391015c6m383b1b1f8788e3c0@mail.gmail.com> <20091102215752.GA27337@soi.city.ac.uk> <2518b95d0911021517l48f903a9k1c8ecb5e07d0379e@mail.gmail.com> Message-ID: <20091102232145.GA6506@soi.city.ac.uk> On Mon, Nov 02, 2009 at 03:17:13PM -0800, Evan Laforge wrote: > On Mon, Nov 2, 2009 at 1:57 PM, Ross Paterson wrote: > > On Mon, Nov 02, 2009 at 01:30:49PM -0700, Evan Laforge wrote: > >> [ ross ] > >> > Proposal: deprecate and then remove find, findIndex, findMin, findMax, > >> > deleteFindMin and deleteFindMax. > >> > >> List.find? No thanks, I use that all the time. > > > > No, Data.(Int)Map.find > > Yeah, I can't find it on > http://www.haskell.org/ghc/docs/latest/html/libraries/containers/Data-Map.html. > What's the signature? My mistake: it's a private version of (!). From qdunkan at gmail.com Mon Nov 2 18:38:39 2009 From: qdunkan at gmail.com (Evan Laforge) Date: Mon Nov 2 18:14:51 2009 Subject: Data.IntMap/IntSet inconsistencies In-Reply-To: <20091102232145.GA6506@soi.city.ac.uk> References: <4AEE0502.7010905@gmail.com> <2518b95d0911021014s793dcd3cv9a597768655b4b2d@mail.gmail.com> <694519c50911021023sf91e2c3gf7158669eee690a3@mail.gmail.com> <2518b95d0911021230n391015c6m383b1b1f8788e3c0@mail.gmail.com> <20091102215752.GA27337@soi.city.ac.uk> <2518b95d0911021517l48f903a9k1c8ecb5e07d0379e@mail.gmail.com> <20091102232145.GA6506@soi.city.ac.uk> Message-ID: <2518b95d0911021538x72e32a75i2dd03f7e40b66616@mail.gmail.com> >> Yeah, I can't find it on >> http://www.haskell.org/ghc/docs/latest/html/libraries/containers/Data-Map.html. >> ?What's the signature? > > My mistake: it's a private version of (!). Ahh, kill away then. I wouldn't mind removing (!) too as long as we're deprecating things :) In the presence of toDescList I agree findMax can go away. From twanvl at gmail.com Mon Nov 2 18:43:41 2009 From: twanvl at gmail.com (Twan van Laarhoven) Date: Mon Nov 2 18:19:45 2009 Subject: Data.IntMap/IntSet inconsistencies In-Reply-To: <2518b95d0911021230n391015c6m383b1b1f8788e3c0@mail.gmail.com> References: <4AEE0502.7010905@gmail.com> <2518b95d0911021014s793dcd3cv9a597768655b4b2d@mail.gmail.com> <694519c50911021023sf91e2c3gf7158669eee690a3@mail.gmail.com> <2518b95d0911021230n391015c6m383b1b1f8788e3c0@mail.gmail.com> Message-ID: <4AEF6EAD.4050002@gmail.com> Evan Laforge wrote: > As far as findMin, toAscList works just as well, so fine, let's kill > it. For findMax, toDescList, which I thought was patched in a year > ago, still doesn't appear in the latest version of collections, so as > far as I know there's no alternative for it. The fact that a function can be written in terms of other things in the library is no excuse not to include it. If a program somewhere needs to find the smallest key in a map, then it should say so! findMin makes the intention of the programmer clear, while toAscList does not. Twan From ross at soi.city.ac.uk Mon Nov 2 18:56:01 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Nov 2 18:32:15 2009 Subject: Data.IntMap/IntSet inconsistencies In-Reply-To: <4AEF6EAD.4050002@gmail.com> References: <4AEE0502.7010905@gmail.com> <2518b95d0911021014s793dcd3cv9a597768655b4b2d@mail.gmail.com> <694519c50911021023sf91e2c3gf7158669eee690a3@mail.gmail.com> <2518b95d0911021230n391015c6m383b1b1f8788e3c0@mail.gmail.com> <4AEF6EAD.4050002@gmail.com> Message-ID: <20091102235601.GA11517@soi.city.ac.uk> On Tue, Nov 03, 2009 at 12:43:41AM +0100, Twan van Laarhoven wrote: > The fact that a function can be written in terms of other things in > the library is no excuse not to include it. If a program somewhere > needs to find the smallest key in a map, then it should say so! > findMin makes the intention of the programmer clear, while toAscList > does not. The safe alternative is minViewWithKey. From martijn at van.steenbergen.nl Tue Nov 3 02:42:35 2009 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Tue Nov 3 02:18:54 2009 Subject: traceM and traceShowM In-Reply-To: <4AD8738A.5080807@van.steenbergen.nl> References: <4AD8738A.5080807@van.steenbergen.nl> Message-ID: <4AEFDEEB.7040304@van.steenbergen.nl> I have submitted a trac ticket: http://hackage.haskell.org/trac/ghc/ticket/3634 Thank you all for your input! Martijn. Martijn van Steenbergen wrote: > Hello, > > I propose the addition of the following two functions to module > Debug.Trace: > >> traceM :: Monad m => String -> m () >> traceM msg = trace msg (return ()) >> >> traceShowM :: (Show a, Monad m) => a -> m () >> traceShowM = traceM . show > > These functions allow tracing in any do-block. I often define them > myself; I think they are useful in general. > > Deadline: 23 October 2009. > > Martijn. > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From wasserman.louis at gmail.com Tue Nov 3 15:39:32 2009 From: wasserman.louis at gmail.com (Louis Wasserman) Date: Tue Nov 3 15:16:01 2009 Subject: Data.Map/Data.IntMap additional features Message-ID: Hey all, Amid the discussion of inconsistencies between Data.IntMap and Data.Map, I thought I'd throw in some more ideas. I've been working on a rather thorough generalized trie map implementation, which has done nothing if not force me to make really very generalized signatures for every method offered by Data.Map, etc. Some of these generalizations are, I think, independently useful, and I wanted to throw them out for discussion before creating a ticket. A function that I call extract/extractWith/extractWithKey: extractWithKey :: Alternative f => (k -> a -> f (z, Maybe a)) -> Map k a -> f (z, Map k a) which is actually defined as follows: > extractWithKey f (Bin n kx x l r) = fmap (\ (z, l') -> (z, Bin n kx x l' r)) (extractWithKey f l) <|> > fmap (\ (z, x') -> (z, maybe (glue l r) (\ xx -> bin kx xx l r) x')) (f kx x) <|> fmap (\ (z, r') -> (z, Bin n kx x l r')) (extractWithKey f r) > extractWithKey f Nil = empty If m is fromList [(k1, x1), (k2, x2), ..., (kn, xn)], then > fst <$> extractWithKey (\ k a -> pure (f k a, )) m == f k1 x1 <|> f k2 x2 <|> ... <|> f kn xn and then the second component is obtained by modifying a single element accordingly and taking the alternative over every element to choose from. A few observations: with an appropriate Alternative instance for Data.Monoid.First and Data.Monoid.Last, > extractWithKey (\ k a -> return ((k, a), Nothing)) m == First (minViewWithKey m) so this generalizes minViewWithKey and maxViewWithKey according to the First Alternative instance. (Note that the extractWithKey implementation is also O(log n), because the natural First Alternative instance will ignore the irrelevant pathways lazily, > extractWithKey (\ k a -> if p k a then pure ((k, a), Nothing) else empty) in the First Alternative instance, will extract the first element of the map that satisfies p, or will return Nothing if there is no such element, and will take O(i) time to do so if the first satisfying element is at index i, > mapPermK :: Int -> Map k a -> [[(k, a)]] > mapPermK 0 m = [[]] > mapPermK (n+1) m = do ((k1, a1), m') <- extractWithKey (\ k a -> return ((k, a), Nothing)) m > liftM ((k1, a1) :) (mapPermK n m) returns a list of all permutations of k distinct associations from the map m, and does it exactly as lazily as one might hope. (Generating combinations efficiently is somewhat harder, and I'm not sure this approach grants much in the way of additional efficiency beyond a couple other approaches I can think of.) In any event, you get the idea: this is a preposterously general method, albeit difficult to describe. It is moderately easier to describe the individual projections, which I name arbitrarily, about :: Alternative f => (k -> a -> f z) -> Map k a -> f z modify :: Alternative f => (k -> a -> f (Maybe a)) -> Map k a -> f (Map k a) Finally, I'll define neighborhood. Internally, neighborhood has the signature neighborhood :: Ord k => k -> Map k a -> (Last (k, a), Maybe a, First (k, a)) where neighborhood k m = (sup [(k', a) | k' < k], lookup k m, inf [(k', a) | k' > k]) == case splitLookup k m of (mL, v, mR) -> (fmap fst (maxViewWithKey mL), v, fmap fst (minViewWithKey mR)) is defined as follows: neighborhood k Tip = (empty, empty, empty) neighborhood k (Bin _ kx x l r) = case compare k kx of LT -> case neighborhood k l of (lb, v, ub) -> (lb, v, ub <|> pure (kx, x)) EQ -> (Last (fmap fst (maxViewWithKey l)), Just x, First (fmap fst (minViewWithKey r))) -- we can also use the *about* generalization here, since we only need the minimum and maximum associations GT -> case neighborhood k r of (lb, v, ub) -> (pure (kx, x) <|> lb, v, ub) Using MonadPlus or Alternative instances for First and Last are rather elegant here, and I strongly support adding their Applicative, Alternative, Monad, and MonadPlus instances to base. Louis Wasserman wasserman.louis@gmail.com http://profiles.google.com/wasserman.louis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20091103/2589a99f/attachment.html From qdunkan at gmail.com Tue Nov 3 18:21:10 2009 From: qdunkan at gmail.com (Evan Laforge) Date: Tue Nov 3 17:57:21 2009 Subject: Data.Map/Data.IntMap additional features In-Reply-To: References: Message-ID: <2518b95d0911031521r622288d1vd405c4f9fbf9e90a@mail.gmail.com> On Tue, Nov 3, 2009 at 12:39 PM, Louis Wasserman wrote: > Hey all, > > Amid the discussion of inconsistencies between Data.IntMap and Data.Map, I > thought I'd throw in some more ideas.? I've been working on a rather > thorough generalized trie map implementation, which has done nothing if not > force me to make really very generalized signatures for every method offered > by Data.Map, etc.? Some of these generalizations are, I think, independently > useful, and I wanted to throw them out for discussion before creating a > ticket. It looks really complicated and I don't really understand any of it. So maybe as a default method for a typeclass that the datatype designer can implement, but if it were a choice between findMax and extractWithKey with some Applicative and Monoid and whatever else magic, I'd use findMax every time :) I'd be wary of putting anything difficult to describe in a default interface for a basic data type. The main functions I use with maps are forward and reverse iteration (toAscList, toDescList) and splitting, I have split2 defined which is more useful to me than Map.splitLookup: -- | Like 'Data.Map.split', except include a matched key in the above map. split2 :: (Ord k) => k -> Map.Map k a -> (Map.Map k a, Map.Map k a) And of course creating, inserting, updating, and deleting. Rarely key and value mapping. Any interface that provides those 9 functions will satisfy all needs I can think of. If they can all be implemented with extractWithKey, then great, put that in the class interface and define the rest with defaulting methods. From midfield at gmail.com Tue Nov 3 18:48:10 2009 From: midfield at gmail.com (Ben) Date: Tue Nov 3 18:24:19 2009 Subject: Data.IntMap/IntSet inconsistencies Message-ID: <9157df230911031548t752ac9fbn39b544f0d29a1c02@mail.gmail.com> while we're on the topic, i'm curious as to why there isn't a zip / join-type method for IntMaps / IntSets. (i use the term join in reference to SQL.) i have defined some in the past like -- maybe not efficient joinOuterWithKey f m1 m2 d1 d2 = M.union (M.intersectionWithKey f m1 m2) $ M.union (M.mapWithKey f1 $ m1 M.\\ m2) (M.mapWithKey f2 $ m2 M.\\ m1) where f1 k l = f k l d2 f2 k r = f k d1 r -- left biased joinLeftWithKey f m1 m2 d2 = M.union (M.intersectionWithKey f m1 m2) (M.mapWithKey f1 $ m1 M.\\ m2) where f1 k a = f k a d2 -- right biased joinRightWithKey f m1 m2 d1 = M.union (M.intersectionWithKey f m1 m2) (M.mapWithKey f2 $ m2 M.\\ m1) where f2 k b = f k d1 b joinInnerWithKey = M.intersectionWithKey but 1) these are probably not terribly efficient, as they do multiple traversals 2) the types are not general enough : like zip you should be able to take functions f : a->b->c instead of what intersectionWith forces you to do (f: a->b->a). the proper implementation should be easy, and trivially generalizes intersectionWith and friends, i believe. or am i missing something? best, ben From s.clover at gmail.com Tue Nov 3 19:23:27 2009 From: s.clover at gmail.com (Sterling Clover) Date: Tue Nov 3 18:59:36 2009 Subject: Data.Map/Data.IntMap additional features In-Reply-To: References: Message-ID: On Tue, Nov 3, 2009 at 3:39 PM, Louis Wasserman wrote: > Using MonadPlus or Alternative instances for First and Last are rather > elegant here, and I strongly support adding their Applicative, Alternative, > Monad, and MonadPlus instances to base. +1 for this. I've had to do it myself more than once. Also the functor instance. --S. From wasserman.louis at gmail.com Tue Nov 3 21:00:14 2009 From: wasserman.louis at gmail.com (Louis Wasserman) Date: Tue Nov 3 20:36:43 2009 Subject: Data.Map/Data.IntMap additional features Message-ID: > > but if it were a choice between findMax and > extractWithKey with some Applicative and Monoid and whatever else > magic, I'd use findMax every time :) I'd be wary of putting anything > difficult to describe in a default interface for a basic data type. > Okay, some restatement required here: I'm suggesting this method *only* for Data.Map and Data.IntMap -- not for anything more common -- and I'm not by any means suggesting that I'd use this in every case over findMin, but merely using findMin as an example application. I *do* think it's okay for a commonly used module to have some advanced methods for advanced users. > And of course creating, inserting, updating, and deleting. Rarely key > and value mapping. Any interface that provides those 9 functions will > satisfy all needs I can think of. If they can all be implemented with > extractWithKey, then great, put that in the class interface and define > the rest with defaulting methods. > Quite honestly, I use key and value mapping all the time, in most applications I need maps for, and extractWithKey generalizes (and makes more efficient) several applications use regularly. Here's one more example of an application that can't be done nicely or efficiently with application of the currently existing methods: extractMinPair :: Map k1 (Map k2 v) -> Maybe (((k1, k2), v), Map k1 (Map k2 v)) extractMinPair m = do ((k1, m1), m') <- minViewWithKey m ((k2, v), m1') <- minViewWithKey m1 return (((k1, k2), v), if null m1' then m' else insert k1 m1' m) (In particular, this is the extractMin implementation from the generalized trie on keys of type (k1, k2), which motivated the method in the first place.) Note that in most cases, we'll need to insert m1' back into m, which is really ugly, and definitely destroys the nicer recursive properties that I'm looking for. Rather, if I can extract information and modify a value from the map with a single use of extractWithKey, extractMinPair m = getFirst $ extractWithKey (\ k1 m1 -> fmap (\ ((k2, v), m1') -> (((k1, k2), v), guardNull m1')) (minViewWithKey m1)) m where guardNull m = if null m then Nothing else Just m In the list of methods you named as particularly critical, you talked about creating, inserting, updating, and deleting; you actually didn't mention looking up values, which I assume you meant to -- since what's the point of the map if you can't look up any values? extractWithKey is useful when I want to look up a value, and edit it, at the same time, without an exra O(log n) pass, and it specifically and elegantly takes care of the case where we want to simultaneously look up and edit the minimum or maximum value of a map. Louis Wasserman wasserman.louis@gmail.com http://profiles.google.com/wasserman.louis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20091103/40a0149f/attachment.html From marlowsd at gmail.com Wed Nov 4 05:00:01 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Nov 4 04:36:28 2009 Subject: Proposal: System.FilePath: current directory should be ".", not "" In-Reply-To: <1253812808.18961.6288.camel@localhost> References: <4AB75CCE.1060709@gmail.com> <1253634191.18961.3032.camel@localhost> <4ABA2006.7010809@gmail.com> <1253812808.18961.6288.camel@localhost> Message-ID: <4AF150A1.3040403@gmail.com> On 24/09/2009 18:20, Duncan Coutts wrote: >> However, there are some oddities with the current proposal. e.g. >> >> splitFileName "./foo" == ("./", "foo") >> "./" "foo" == "./foo" >> >> The current proposal just about hangs together because the tiny bit of >> normalisation that does exactly undoes the creation of "." in >> splitFileName, and there's no other way that splitFileName can generate >> ".". That's a terribly fragile property. > > So if we take the first bit of your proposal and not the second we have: > > splitFileName "foo" == ("./", "foo") > "./" "foo" == "./foo" > > and thus we do not have: > > uncurry () (splitFileName x) == x > > because we end up with "foo" an "./foo" > > However I think that's fine. The splitFileName function is asking for > the directory part of a relative/incomplete filepath and expecting it to > be a real directory. Thus we are interpreting the original filepath as a > complete filepath that is relative to ".". So given that by applying > splitFileName we are taking that interpretation it's ok to get back > "./foo", because we in that context we really were interpreting "foo" as > "./foo". I've amended the patch as suggested above, it turned out to be not too hard. A few places were using splitFileName internally, and that broke some properties, e.g. -- > Valid x => replaceFileName x (takeFileName x) == x replaceFileName :: FilePath -> String -> FilePath replaceFileName x y = dropFileName x y the property doesn't hold any more because dropFileName "foo" == "./". So I worked around cases like this with an internal version of splitFileName with the old semantics. This isn't a big problem - it just means we get to keep some of these nice simple equality properties, which are arguably wrong anyway, and fewer "./" prefixes will show up to surprise users. Neil's comprehensive test suite still passes with the new patch. Ticket, with new patch attached: http://hackage.haskell.org/trac/ghc/ticket/2034 The discussion deadline has long passed, so I propose we have another 2 weeks (18 November). Cheers, Simon From duncan.coutts at googlemail.com Wed Nov 4 06:11:49 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Wed Nov 4 05:48:00 2009 Subject: Proposal: System.FilePath: current directory should be ".", not "" In-Reply-To: <4AF150A1.3040403@gmail.com> References: <4AB75CCE.1060709@gmail.com> <1253634191.18961.3032.camel@localhost> <4ABA2006.7010809@gmail.com> <1253812808.18961.6288.camel@localhost> <4AF150A1.3040403@gmail.com> Message-ID: <1257333109.25369.2555.camel@localhost> On Wed, 2009-11-04 at 10:00 +0000, Simon Marlow wrote: > I've amended the patch as suggested above, it turned out to be not too > hard. [..] > Neil's comprehensive test suite still passes with the new patch. > > Ticket, with new patch attached: > > http://hackage.haskell.org/trac/ghc/ticket/2034 > > The discussion deadline has long passed, so I propose we have another 2 > weeks (18 November). I support this new proposal. To summarise for people who have not been paying full attention: Currently: takeDirectory "Main.hs" = "" Proposed: takeDirectory "Main.hs" = "./" The purpose being that one can always take the directory and get a valid path to use with a file system function, eg createDirectory. Unchanged behaviour: "./" "Main.hs" = "./Main.hs" It was initially proposed that eat "./" on the left hand side but the current proposal leaves the behaviour of unchanged. Duncan From nicolas.pouillard at gmail.com Wed Nov 4 06:16:57 2009 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Wed Nov 4 05:53:05 2009 Subject: Proposal: System.FilePath: current directory should be ".", not "" In-Reply-To: <1257333109.25369.2555.camel@localhost> References: <4AB75CCE.1060709@gmail.com> <1253634191.18961.3032.camel@localhost> <4ABA2006.7010809@gmail.com> <1253812808.18961.6288.camel@localhost> <4AF150A1.3040403@gmail.com> <1257333109.25369.2555.camel@localhost> Message-ID: <1257333406-sup-8462@peray> Excerpts from Duncan Coutts's message of Wed Nov 04 12:11:49 +0100 2009: > On Wed, 2009-11-04 at 10:00 +0000, Simon Marlow wrote: > > > I've amended the patch as suggested above, it turned out to be not too > > hard. > > [..] > > > Neil's comprehensive test suite still passes with the new patch. > > > > Ticket, with new patch attached: > > > > http://hackage.haskell.org/trac/ghc/ticket/2034 > > > > The discussion deadline has long passed, so I propose we have another 2 > > weeks (18 November). > > I support this new proposal. So do I. -- Nicolas Pouillard http://nicolaspouillard.fr From malcolm.wallace at cs.york.ac.uk Wed Nov 4 06:26:08 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Nov 4 06:02:49 2009 Subject: Proposal: System.FilePath: current directory should be ".", not "" In-Reply-To: <1257333406-sup-8462@peray> References: <4AB75CCE.1060709@gmail.com> <1253634191.18961.3032.camel@localhost> <4ABA2006.7010809@gmail.com> <1253812808.18961.6288.camel@localhost> <4AF150A1.3040403@gmail.com> <1257333109.25369.2555.camel@localhost> <1257333406-sup-8462@peray> Message-ID: <63749D3A-0AA9-4951-BD03-F878EF60CFF7@cs.york.ac.uk> >>> http://hackage.haskell.org/trac/ghc/ticket/2034 >>> >>> The discussion deadline has long passed, so I propose we have >>> another 2 >>> weeks (18 November). >> >> I support this new proposal. > > So do I. +1. Regards, Malcolm From felipe.lessa at gmail.com Wed Nov 4 06:56:11 2009 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Wed Nov 4 06:32:19 2009 Subject: Proposal: System.FilePath: current directory should be ".", not "" In-Reply-To: <4AF150A1.3040403@gmail.com> References: <4AB75CCE.1060709@gmail.com> <1253634191.18961.3032.camel@localhost> <4ABA2006.7010809@gmail.com> <1253812808.18961.6288.camel@localhost> <4AF150A1.3040403@gmail.com> Message-ID: On Wed, Nov 4, 2009 at 8:00 AM, Simon Marlow wrote: > the property doesn't hold any more because dropFileName "foo" == "./". So I > worked around cases like this with an internal version of splitFileName with > the old semantics. ?This isn't a big problem - it just means we get to keep > some of these nice simple equality properties, which are arguably wrong > anyway, and fewer "./" prefixes will show up to surprise users. If FilePath was a newtype, could its Eq instance not distinguish between "foo" and "./foo"? Note that we must distinguish "./foo/../" of "./" because this may not be valid ("foo" does not exist) or may be something different ("foo" is a symlink). This Eq instance would just eat all superfluous "./". Cheers, -- Felipe. From marlowsd at gmail.com Wed Nov 4 07:27:49 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Nov 4 07:04:01 2009 Subject: Proposal: System.FilePath: current directory should be ".", not "" In-Reply-To: References: <4AB75CCE.1060709@gmail.com> <1253634191.18961.3032.camel@localhost> <4ABA2006.7010809@gmail.com> <1253812808.18961.6288.camel@localhost> <4AF150A1.3040403@gmail.com> Message-ID: <4AF17345.8080504@gmail.com> On 04/11/2009 11:56, Felipe Lessa wrote: > On Wed, Nov 4, 2009 at 8:00 AM, Simon Marlow wrote: >> the property doesn't hold any more because dropFileName "foo" == "./". So I >> worked around cases like this with an internal version of splitFileName with >> the old semantics. This isn't a big problem - it just means we get to keep >> some of these nice simple equality properties, which are arguably wrong >> anyway, and fewer "./" prefixes will show up to surprise users. > > If FilePath was a newtype, could its Eq instance not distinguish > between "foo" and "./foo"? Note that we must distinguish "./foo/../" > of "./" because this may not be valid ("foo" does not exist) or may be > something different ("foo" is a symlink). This Eq instance would just > eat all superfluous "./". Yes, but FilePath is not a newtype, and it would break a lot of code to make it one. That is not part of this proposal. Just in case this isn't clear: like most people, I (still) believe FilePath should be an abstract type, but that's a matter for separate discussion. Right now I'm concerned about fixing a small problem with the current API. Cheers, Simon From marlowsd at gmail.com Wed Nov 4 10:28:47 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Nov 4 10:05:01 2009 Subject: Network library broken on Windows with GHC 6.12rc1 In-Reply-To: <90889fe70910220959r35a44225iffcd0606b8d511f5@mail.gmail.com> References: <90889fe70910220707p688046b5xaa93037792a6504b@mail.gmail.com> <001636c5bc3f2de0ac047688d34c@google.com> <90889fe70910220959r35a44225iffcd0606b8d511f5@mail.gmail.com> Message-ID: <4AF19DAF.9090806@gmail.com> On 22/10/2009 17:59, Johan Tibell wrote: > Hi, > > Thanks for filing the bug report. > > I did have a Windows setup but I haven't had time to set it all up > again on my new laptop (read: it's a pain). There is a buildbot > building the network package (I believe Ian added the repo to the list > of repos to build). However, it doesn't provide reports in any > convenient format so I have to remember to check it manually from time > to time. > > Bryan has access to a Windows machine and has been doing most of the > Windows related changes. > > Patches welcome. > > -- Johan > > P.S. The network package is a mess. Full of ifdefs, has no tests and > is prone to breakage. I've started looking into how it could be made > better but I don't have time for any major hacking at the moment. It does have tests, three to be precise, in the tests/ subdirectory. They are set up to be used with the GHC test suite framework, but it wouldn't be hard to adapt them to whatever framework you want to use. Cheers, Simon From marlowsd at gmail.com Wed Nov 4 10:40:06 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Nov 4 10:16:25 2009 Subject: traceM and traceShowM In-Reply-To: <4AD8738A.5080807@van.steenbergen.nl> References: <4AD8738A.5080807@van.steenbergen.nl> Message-ID: <4AF1A056.8010306@gmail.com> On 16/10/2009 14:22, Martijn van Steenbergen wrote: > Hello, > > I propose the addition of the following two functions to module > Debug.Trace: > >> traceM :: Monad m => String -> m () >> traceM msg = trace msg (return ()) >> >> traceShowM :: (Show a, Monad m) => a -> m () >> traceShowM = traceM . show is traceShowM really necessary? It doesn't save many characters, and fails the "don't name a composition" test. Cheers, Simon From p.k.f.holzenspies at utwente.nl Wed Nov 4 10:59:56 2009 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?ISO-8859-1?Q?H=F6lzenspies?=) Date: Wed Nov 4 10:36:02 2009 Subject: traceM and traceShowM In-Reply-To: <4AF1A056.8010306@gmail.com> References: <4AD8738A.5080807@van.steenbergen.nl> <4AF1A056.8010306@gmail.com> Message-ID: <1257350396.2566.8.camel@ewi1043> On Wed, 2009-11-04 at 15:40 +0000, Simon Marlow wrote: > On 16/10/2009 14:22, Martijn van Steenbergen wrote: > > Hello, > > > > I propose the addition of the following two functions to module > > Debug.Trace: > > > >> traceM :: Monad m => String -> m () > >> traceM msg = trace msg (return ()) > >> > >> traceShowM :: (Show a, Monad m) => a -> m () > >> traceShowM = traceM . show > > is traceShowM really necessary? It doesn't save many characters, and > fails the "don't name a composition" test. As a post-deadline suggestion to fix Simon's (valid) reservation: traceShowM :: (Show a, Monad m) => a -> m a traceShowM a = traceM (show a) a This allows easier trace insertion, e.g.: foo a = do x <- bar a y <- frop x becomes foo a = do x <- bar a >>= traceShowM y <- frop x >>= traceShowM This, to me, looks like a nice syntactic solution. Regards, Philip PS. Is there some seq/deep_seq/strict/whatever solution for the lazy monads problem hiding in here somewhere? From p.k.f.holzenspies at utwente.nl Wed Nov 4 11:04:56 2009 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?ISO-8859-1?Q?H=F6lzenspies?=) Date: Wed Nov 4 10:41:03 2009 Subject: traceM and traceShowM In-Reply-To: <1257350396.2566.8.camel@ewi1043> References: <4AD8738A.5080807@van.steenbergen.nl> <4AF1A056.8010306@gmail.com> <1257350396.2566.8.camel@ewi1043> Message-ID: <1257350696.2566.10.camel@ewi1043> On Wed, 2009-11-04 at 16:59 +0100, Philip K.F. H?lzenspies wrote: > traceShowM :: (Show a, Monad m) => a -> m a > traceShowM a = traceM (show a) a Sorry, shouldn't write and send e-mails so quickly. Obvious / corrected version: traceShowM a = traceM (show a) >> return a Ph. From johan.tibell at gmail.com Wed Nov 4 11:50:44 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed Nov 4 11:27:11 2009 Subject: Network library broken on Windows with GHC 6.12rc1 In-Reply-To: <4AF19DAF.9090806@gmail.com> References: <90889fe70910220707p688046b5xaa93037792a6504b@mail.gmail.com> <001636c5bc3f2de0ac047688d34c@google.com> <90889fe70910220959r35a44225iffcd0606b8d511f5@mail.gmail.com> <4AF19DAF.9090806@gmail.com> Message-ID: <90889fe70911040850p32efe2a9ue9a11f485aca3f6@mail.gmail.com> On Wed, Nov 4, 2009 at 4:28 PM, Simon Marlow wrote: > It does have tests, three to be precise, in the tests/ subdirectory. They > are set up to be used with the GHC test suite framework, but it wouldn't be > hard to adapt them to whatever framework you want to use. They didn't work at the time I tried them but perhaps I was doing things incorrectly. Regardless I need to write a proper testsuite. network-bytestring already has pretty good coverage for the send/recv type functions that I could reuse. -- Johan From wasserman.louis at gmail.com Wed Nov 4 14:57:40 2009 From: wasserman.louis at gmail.com (Louis Wasserman) Date: Wed Nov 4 14:34:07 2009 Subject: Data.IntMap/IntSet inconsistencies Message-ID: > > 2) the types are not general enough : like zip you should be able to > take functions f : a->b->c instead of what intersectionWith forces you > to do (f: a->b->a). > According to my documentation, the type of intersectionWith *is* (f :: a -> b -> c). On another note, with respect to my proposed change: I concede that it might be too general for some people. Here's a simpler change that I'd like: to be able to project information out of a value and modify it simultaneously, so simply alterProject :: (Maybe a -> (z, Maybe a)) -> k -> Map k a -> (z, Map k a ) for a specific key. and perhaps something similar for the min/max operations. I'd very much like to be able to do more general things than just min/max operations with this sort of generality -- hence the Alternative approach in my original proposal. Louis Wasserman wasserman.louis@gmail.com http://profiles.google.com/wasserman.louis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20091104/27e562d6/attachment.html From midfield at gmail.com Wed Nov 4 15:09:45 2009 From: midfield at gmail.com (Ben) Date: Wed Nov 4 14:46:05 2009 Subject: Data.IntMap/IntSet inconsistencies In-Reply-To: References: Message-ID: <9157df230911041209q43162d2ambf31fcb2613e7b13@mail.gmail.com> On Wed, Nov 4, 2009 at 11:57 AM, Louis Wasserman wrote: > > According to my documentation, the type of intersectionWith is (f :: a -> b > -> c). apologies, i'm using 6.10 so apparently my containers library is out of date. i guess this is another reason to upgrade to 6.12: http://www.haskell.org/ghc/dist/current/docs/html/users_guide/release-6-12-1.html 1.5.9.5. containers Version number 0.3.0.0 (was 0.2.0.1) mapAccumRWithKey has been added to Data.IntMap. A Traversable instance has been added to Data.IntMap.IntMap. The types of Data.IntMap.intersectionWith and Data.IntMap.intersectionWithKey have been changed from intersectionWith :: (a -> b -> a) -> IntMap a -> IntMap b -> IntMap a intersectionWithKey :: (Key -> a -> b -> a) -> IntMap a -> IntMap b -> IntMap a to intersectionWith :: (a -> b -> c) -> IntMap a -> IntMap b -> IntMap c intersectionWithKey :: (Key -> a -> b -> c) -> IntMap a -> IntMap b -> IntMap c b From martijn at van.steenbergen.nl Thu Nov 5 07:25:13 2009 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Thu Nov 5 07:01:25 2009 Subject: traceM and traceShowM In-Reply-To: <4AF1A056.8010306@gmail.com> References: <4AD8738A.5080807@van.steenbergen.nl> <4AF1A056.8010306@gmail.com> Message-ID: <4AF2C429.1080901@van.steenbergen.nl> Simon Marlow wrote: > On 16/10/2009 14:22, Martijn van Steenbergen wrote: >> Hello, >> >> I propose the addition of the following two functions to module >> Debug.Trace: >> >>> traceM :: Monad m => String -> m () >>> traceM msg = trace msg (return ()) >>> >>> traceShowM :: (Show a, Monad m) => a -> m () >>> traceShowM = traceM . show > > is traceShowM really necessary? It doesn't save many characters, and > fails the "don't name a composition" test. No, it's not necessary at all. There's a bit of tension between not wanting to name a composition and being consistent with the rest of the module: traceM and traceShowM mirror the existing trace and traceShow functions. Martijn. From martijn at van.steenbergen.nl Thu Nov 5 07:34:07 2009 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Thu Nov 5 07:10:23 2009 Subject: traceM and traceShowM In-Reply-To: <1257350396.2566.8.camel@ewi1043> References: <4AD8738A.5080807@van.steenbergen.nl> <4AF1A056.8010306@gmail.com> <1257350396.2566.8.camel@ewi1043> Message-ID: <4AF2C63F.5090906@van.steenbergen.nl> Philip K.F. H?lzenspies wrote: > As a post-deadline suggestion to fix Simon's (valid) reservation: > > traceShowM :: (Show a, Monad m) => a -> m a > traceShowM a = traceM (show a) a > > This allows easier trace insertion, e.g.: I disagree. I think it's easier to remove/comment/uncomment (which you do often with trace statements) a whole line than part of a line. On the other hand, you can still use this function as a standalone line. But I don't like having monadic functions return something when that's not necessary, even though I cannot think of a clear argument against it at the moment. :-( So I guess either way is fine. Does anyone else know any criteria to decide one way or another? Martijn. From ndmitchell at gmail.com Thu Nov 5 15:36:30 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Nov 5 15:12:34 2009 Subject: Proposal: System.FilePath: current directory should be ".", not "" In-Reply-To: <1257333109.25369.2555.camel@localhost> References: <4AB75CCE.1060709@gmail.com> <1253634191.18961.3032.camel@localhost> <4ABA2006.7010809@gmail.com> <1253812808.18961.6288.camel@localhost> <4AF150A1.3040403@gmail.com> <1257333109.25369.2555.camel@localhost> Message-ID: <404396ef0911051236r58cab85dt1cf19fa316eec048@mail.gmail.com> I agree with the idea behind this proposal, but am pretty sure it will break quite a few filepath things that I maintain. So +1, but also +1 for a really strong release announcement and version bump. The problem with filepaths is that they lack much structure, and are very system dependent - meaning every change will break something. A lovely abstract type would be wonderful, but no one has yet released such a library on hackage... Thanks, Neil 2009/11/4 Duncan Coutts : > On Wed, 2009-11-04 at 10:00 +0000, Simon Marlow wrote: > >> I've amended the patch as suggested above, it turned out to be not too >> hard. > > [..] > >> Neil's comprehensive test suite still passes with the new patch. >> >> Ticket, with new patch attached: >> >> ? ?http://hackage.haskell.org/trac/ghc/ticket/2034 >> >> The discussion deadline has long passed, so I propose we have another 2 >> weeks (18 November). > > I support this new proposal. > > > To summarise for people who have not been paying full attention: > > Currently: > ? ? ? ?takeDirectory "Main.hs" ?= ?"" > > Proposed: > ? ? ? ?takeDirectory "Main.hs" ?= ?"./" > > The purpose being that one can always take the directory and get a valid > path to use with a file system function, eg createDirectory. > > > Unchanged behaviour: > > ? ? ? ?"./" "Main.hs" ?= ?"./Main.hs" > > It was initially proposed that eat "./" on the left hand side but > the current proposal leaves the behaviour of unchanged. > > Duncan > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From lemming at henning-thielemann.de Thu Nov 5 17:50:37 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Nov 5 17:26:52 2009 Subject: seq as type class method Message-ID: I have read in the History of Haskell, that originally 'seq' should be a method of a type class, that can be automatically derived by a 'deriving' clause. It was also mentioned that this clean solution was dropped because of particular experiences with developing a parser. However the arguments appeared to me, like these were problems of debugging. I think that hacks are ok for debugging, such as dynamically finding a Show method for a message for 'error', although no Show constraint was given in the type signature. But I think that hacks are not ok for regular programming. In the History of Haskell it is told that the hack of making 'seq' not a member of a type class leads to invalid fusion optimization. While it is not possible to get rid of 'seq' anymore, wouldn't it be feasible to define a new type class with a new 'seq' - maybe just a new module, from where I can import the new 'seq' instead of the one from Prelude? This would also allow us to handle cases like this one: When I have a datatype like data T = A | B | C and I use 'seq' for it a lot, and once I have to switch to data T = Cons Int S data S = A | B | C and I like that 'seq' on T is strict both on Cons and on the constructors of S, this would be possible using a custom instance Seq T. Actually in stream-fusion:Data.Stream I found such a class, called Unlifted. How about moving this into a separate package? class Unlifted a where -- | This expose function needs to be called in folds/loops that consume -- streams to expose the structure of the stream state to the simplifier -- In particular, to SpecConstr. -- expose :: a -> b -> b expose = seq -- | This makes GHC's optimiser happier; it sometimes produces really bad -- code for single-method dictionaries -- unlifted_dummy :: a unlifted_dummy = error "unlifted_dummy" From stefan at cs.uu.nl Thu Nov 5 18:13:18 2009 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Thu Nov 5 17:49:23 2009 Subject: seq as type class method In-Reply-To: References: Message-ID: <545F6AD0-EE91-4BE3-BC4C-F190A507A6DA@cs.uu.nl> Henning, > I have read in the History of Haskell, that originally 'seq' should > be a method of a type class, that can be automatically derived by a > 'deriving' clause. It was also mentioned that this clean solution > was dropped because of particular experiences with developing a > parser. However the arguments appeared to me, like these were > problems of debugging. If I understood it correctly, the problem was more general than just debugging. Every introduction of seq in a function could result in the requirement to also adapt the type signatures of calling functions. What wasn't understood by then is that making a seq a type-class method is not enough to recover parametricity, which was the goal. This is explained in a recent paper by Daniel Seidel and Janis Voigtlaender: Daniel Seidel and Janis Voigtlaender. Taming selective strictness. In Stefan Fischer, Erik Maehle, and Ruediger Reischuk, editors, INFORMATIK 2009 ? Im Focus das Leben, Beitraege der 39. Jahrestagung der Gesellschaft fuer Informatik e.V. (GI), 28. September ? 2. Oktober, in Luebeck, volume 154 of Lecture Notes in Informatics, pages 2916?2930. GI, 2009. http://www.iai.uni-bonn.de/~jv/atps09.pdf Cheers, Stefan From lemming at henning-thielemann.de Thu Nov 5 18:24:46 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Nov 5 18:00:50 2009 Subject: seq as type class method In-Reply-To: <545F6AD0-EE91-4BE3-BC4C-F190A507A6DA@cs.uu.nl> References: <545F6AD0-EE91-4BE3-BC4C-F190A507A6DA@cs.uu.nl> Message-ID: On Fri, 6 Nov 2009, Stefan Holdermans wrote: > Henning, > >> I have read in the History of Haskell, that originally 'seq' should be a >> method of a type class, that can be automatically derived by a 'deriving' >> clause. It was also mentioned that this clean solution was dropped because >> of particular experiences with developing a parser. However the arguments >> appeared to me, like these were problems of debugging. > > If I understood it correctly, the problem was more general than just > debugging. Every introduction of seq in a function could result in the > requirement to also adapt the type signatures of calling functions. Sure, but why was this a problem? Because they had to re-arrange a lot, and had to change the signature each time. But once that re-arrangement settles, it would be nice to have the Seq type constraint, right? > What wasn't understood by then is that making a seq a type-class method is > not enough to recover parametricity, which was the goal. This is explained in > a recent paper by Daniel Seidel and Janis Voigtlaender: > > Daniel Seidel and Janis Voigtlaender. Taming selective strictness. I'll have a look into it. Thanks for the hint! From niklas.broberg at gmail.com Thu Nov 5 19:13:01 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Thu Nov 5 18:49:06 2009 Subject: Three patches for cabal In-Reply-To: <1245230688.13502.2939.camel@localhost> References: <1245230688.13502.2939.camel@localhost> Message-ID: >> Second there's the constructor NoMonoPatBinds, which actually >> describes the default Haskell 98 behavior, even if GHC has a different >> default. It's GHC's behavior that is the extension, so the constructor >> in cabal should really be named MonoPatBinds. >> >> Also, the PatternSignatures constructor has been deprecated in GHC and >> superceded by ScopedTypeVariables. > > Can someone please comment on these two proposed changes. I agree with > Niklas but I'm a bit reluctant to apply the patches without at least > some sign of agreement from someone else. > > Deprecating PatternSignatures seems uncontroversial, but the > NoMonoPatBinds is potentially controversial. GHC essentially uses > -XMonoPatBinds by default, even in H98 mode, and the user can use > -XNoMonoPatBinds to restore H98 behaviour. Niklas's and my point is that > the list of language extensions in Language.Haskell.Exceptions are > differences from H98 so it should be MonoPatBinds to get the difference > not NoMonoPatBinds to restore H98. > > In practise, since ghc uses MonoPatBinds by default it'd mean that > people who want to get back to H98 would need to use: > > ?ghc-options: -XNoMonoPatBinds > > Because the extensions field is additive, not subtractive. Using the > name MonoPatBinds allows other compilers to implement it without it > having to be the default. I had a look at the source for cabal HEAD and was surprised to see that this stuff had fallen by the wayside. What's holding it up? I can't imagine that anyone would be against the deprecation of PatternSignatures at least. Cheers, /Niklas From stefan at cs.uu.nl Fri Nov 6 01:38:47 2009 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Fri Nov 6 01:14:50 2009 Subject: seq as type class method In-Reply-To: References: <545F6AD0-EE91-4BE3-BC4C-F190A507A6DA@cs.uu.nl> Message-ID: <8036A854-1CB1-4A2C-AD87-F7F7D4B64BDA@cs.uu.nl> Henning, >> If I understood it correctly, the problem was more general than >> just debugging. Every introduction of seq in a function could >> result in the requirement to also adapt the type signatures of >> calling functions. > Sure, but why was this a problem? Because they had to re-arrange a > lot, and had to change the signature each time. But once that re- > arrangement settles, it would be nice to have the Seq type > constraint, right? I cannot tell whether *I* would find it problematic in practice. Hudak et al. write: "However, the limitations of this solution soon became apparent. Inspired by the Fox project at CMU, two of Hughes?s students implemented a TCP/IP stack in Haskell, making heavy use of polymorphism in the different layers. Their code turned out to contain serious space leaks, which they attempted to ?x using seq. But whenever they inserted a call of seq on a type variable, the type signature of the enclosing function changed to require an Eval instance for that variable?just as the designers of Haskell 1.3 intended. But often, the type signatures of very many functions changed as a consequence of a single seq. This would not have mattered if the type signatures were inferred by the compiler?but the students had written them explicitly in their code. Moreover, they had done so not from choice, but because Haskell?s monomorphism restriction required type signatures on these particular definitions [...]. As a result, each insertion of a seq became a nightmare, requiring repeated compilations to ?nd affected type signatures and manual correction of each one. Since space debugging is to some extent a question of trial and error, the students needed to insert and remove calls of seq time and time again. In the end they were forced to conclude that ?xing their space leaks was simply not feasible in the time available to complete the project?not because they were hard to ?nd, but because making the necessary corrections was simply too heavyweight. This experience provided ammunition for the eventual removal of class Eval in Haskell 98." Cheers, Stefan From simonpj at microsoft.com Fri Nov 6 05:38:27 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Nov 6 05:14:32 2009 Subject: seq as type class method In-Reply-To: References: Message-ID: <59543203684B2244980D7E4057D5FBC1061C08F8@DB3EX14MBXC310.europe.corp.microsoft.com> | -- | This makes GHC's optimiser happier; it sometimes produces really bad | -- code for single-method dictionaries | -- | unlifted_dummy :: a | unlifted_dummy = error "unlifted_dummy" If you have such cases, please please boil it down and file it as a bug. We should get *better* code not worse for single-method dictionaries. Simon From ekmett at gmail.com Fri Nov 6 10:11:13 2009 From: ekmett at gmail.com (Edward Kmett) Date: Fri Nov 6 09:47:15 2009 Subject: seq as type class method In-Reply-To: <8036A854-1CB1-4A2C-AD87-F7F7D4B64BDA@cs.uu.nl> References: <545F6AD0-EE91-4BE3-BC4C-F190A507A6DA@cs.uu.nl> <8036A854-1CB1-4A2C-AD87-F7F7D4B64BDA@cs.uu.nl> Message-ID: <7fb8f82f0911060711q5aaa2bd8h78d37a070e1e4c0d@mail.gmail.com> I always thought that story was a bit unfortunate -- mostly because I don't believe a good solution emerged. I also find it odd that they felt the need to continually _remove_ Eval annotations. Leaving an unused extraneous Eval annotation in place should be mostly harmless, An extra dictionary being passed around here or there shouldn't destroy performance too badly -- you only need to pass them in when you are polymorphic in the argument type, and how often is your code really polymorphic _in something you want to arbitrarily seq_ in a performance sensitive part of your TCP/IP stack? Asking to seq a polymorphic argument these days is generally taken as a sign that you are sprinkling seq's around without understanding why. We have strategies now for a reason. -Edward Kmett On Fri, Nov 6, 2009 at 1:38 AM, Stefan Holdermans wrote: > Henning, > > > If I understood it correctly, the problem was more general than just >>> debugging. Every introduction of seq in a function could result in the >>> requirement to also adapt the type signatures of calling functions. >>> >> > Sure, but why was this a problem? Because they had to re-arrange a lot, >> and had to change the signature each time. But once that re-arrangement >> settles, it would be nice to have the Seq type constraint, right? >> > > I cannot tell whether *I* would find it problematic in practice. Hudak et > al. write: > > "However, the limitations of this solution soon became apparent. > Inspired by the Fox project at CMU, two of Hughes?s students > implemented a TCP/IP stack in Haskell, making heavy use of > polymorphism in the different layers. Their code turned out to > contain serious space leaks, which they attempted to ?x using > seq. But whenever they inserted a call of seq on a type > variable, the type signature of the enclosing function changed > to require an Eval instance for that variable?just as the > designers of Haskell 1.3 intended. But often, the type > signatures of very many functions changed as a consequence of a > single seq. This would not have mattered if the type signatures > were inferred by the compiler?but the students had written them > explicitly in their code. Moreover, they had done so not from > choice, but because Haskell?s monomorphism restriction required > type signatures on these particular definitions [...]. As a > result, each insertion of a seq became a nightmare, requiring > repeated compilations to ?nd affected type signatures and > manual correction of each one. Since space debugging is to some > extent a question of trial and error, the students needed to > insert and remove calls of seq time and time again. In the end > they were forced to conclude that ?xing their space leaks was > simply not feasible in the time available to complete the > project?not because they were hard to ?nd, but because making > the necessary corrections was simply too heavyweight. This > experience provided ammunition for the eventual removal of class > Eval in Haskell 98." > > Cheers, > > Stefan_______________________________________________ > > 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/20091106/a2ca5640/attachment-0001.html From lemming at henning-thielemann.de Fri Nov 6 10:16:09 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Nov 6 09:52:12 2009 Subject: seq as type class method In-Reply-To: <8036A854-1CB1-4A2C-AD87-F7F7D4B64BDA@cs.uu.nl> References: <545F6AD0-EE91-4BE3-BC4C-F190A507A6DA@cs.uu.nl> <8036A854-1CB1-4A2C-AD87-F7F7D4B64BDA@cs.uu.nl> Message-ID: On Fri, 6 Nov 2009, Stefan Holdermans wrote: > Henning, > >> Sure, but why was this a problem? Because they had to re-arrange a lot, and >> had to change the signature each time. But once that re-arrangement >> settles, it would be nice to have the Seq type constraint, right? > > I cannot tell whether *I* would find it problematic in practice. Hudak et al. > write: > > "However, the limitations of this solution soon became apparent. > Inspired by the Fox project at CMU, two of Hughes?s students > implemented a TCP/IP stack in Haskell, making heavy use of > polymorphism in the different layers. ... Yes, I think that this is the paragraph that can also be found in the History of Haskell. I might add that better refactoring tools could also have been a solution, right? From stefan at cs.uu.nl Fri Nov 6 10:25:07 2009 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Fri Nov 6 10:01:09 2009 Subject: seq as type class method In-Reply-To: References: <545F6AD0-EE91-4BE3-BC4C-F190A507A6DA@cs.uu.nl> <8036A854-1CB1-4A2C-AD87-F7F7D4B64BDA@cs.uu.nl> Message-ID: <7AE250CC-544F-4E46-A173-203CD70A3905@cs.uu.nl> Henning, >> I cannot tell whether *I* would find it problematic in practice. >> Hudak et al. write: >> "However, the limitations of this solution soon became apparent. >> Inspired by the Fox project at CMU, two of Hughes?s students >> implemented a TCP/IP stack in Haskell, making heavy use of >> polymorphism in the different layers. ... > Yes, I think that this is the paragraph that can also be found in > the History of Haskell. I might add that better refactoring tools > could also have been a solution, right? Agreed. Cheers, Stefan From lemming at henning-thielemann.de Sat Nov 7 15:36:38 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Nov 7 15:12:40 2009 Subject: seq as type class method In-Reply-To: <545F6AD0-EE91-4BE3-BC4C-F190A507A6DA@cs.uu.nl> References: <545F6AD0-EE91-4BE3-BC4C-F190A507A6DA@cs.uu.nl> Message-ID: On Fri, 6 Nov 2009, Stefan Holdermans wrote: > What wasn't understood by then is that making a seq a type-class method is > not enough to recover parametricity, which was the goal. This is explained in > a recent paper by Daniel Seidel and Janis Voigtlaender: > > Daniel Seidel and Janis Voigtlaender. Taming selective strictness. > In Stefan Fischer, Erik Maehle, and Ruediger Reischuk, editors, > INFORMATIK 2009 ? Im Focus das Leben, Beitraege der 39. > Jahrestagung der Gesellschaft fuer Informatik e.V. (GI), 28. > September ? 2. Oktober, in Luebeck, volume 154 of Lecture Notes > in Informatics, pages 2916?2930. GI, 2009. > > http://www.iai.uni-bonn.de/~jv/atps09.pdf I'm still trying to understand the initial example. As far as I can see, in all of these examples an Eval constraint would prevent wrong application of implications/rules, but it might prevent application of a rule when it could be correctly applied. Is my conclusion valid? From ndmitchell at gmail.com Mon Nov 9 06:32:01 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Nov 9 06:07:55 2009 Subject: seq as type class method In-Reply-To: <59543203684B2244980D7E4057D5FBC1061C08F8@DB3EX14MBXC310.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC1061C08F8@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: <404396ef0911090332m621a659br3cf5bb74f4648d83@mail.gmail.com> > | ? ?-- | This makes GHC's optimiser happier; it sometimes produces really bad > | ? ?-- code for single-method dictionaries > | ? ?-- > | ? ?unlifted_dummy :: a > | ? ?unlifted_dummy = error "unlifted_dummy" > > If you have such cases, please please boil it down and file it as a bug. ?We should get *better* code not worse for > single-method dictionaries. I benchmarked this when doing the Uniplate work - 1-member classes gave a noticeable performance benefit over 2 or more members. I think it was 6% or so in my setup, and as a result Uniplate has a single member type class. Thanks, Neil From lemming at henning-thielemann.de Mon Nov 9 07:19:39 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Nov 9 06:55:44 2009 Subject: seq as type class method In-Reply-To: <404396ef0911090332m621a659br3cf5bb74f4648d83@mail.gmail.com> References: <59543203684B2244980D7E4057D5FBC1061C08F8@DB3EX14MBXC310.europe.corp.microsoft.com> <404396ef0911090332m621a659br3cf5bb74f4648d83@mail.gmail.com> Message-ID: On Mon, 9 Nov 2009, Neil Mitchell wrote: >> | ? ?-- | This makes GHC's optimiser happier; it sometimes produces really bad >> | ? ?-- code for single-method dictionaries >> | ? ?-- >> | ? ?unlifted_dummy :: a >> | ? ?unlifted_dummy = error "unlifted_dummy" >> >> If you have such cases, please please boil it down and file it as a bug. ?We should get *better* code not worse for >> single-method dictionaries. > > I benchmarked this when doing the Uniplate work - 1-member classes > gave a noticeable performance benefit over 2 or more members. I think > it was 6% or so in my setup, and as a result Uniplate has a single > member type class. I assume the case in stream-fusion:Data.Stream was vice versa: A one member class seemed to make performance worse .Thus they added a dummy method. From duncan.coutts at googlemail.com Mon Nov 9 07:31:34 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon Nov 9 07:07:30 2009 Subject: Three patches for cabal In-Reply-To: References: <1245230688.13502.2939.camel@localhost> Message-ID: <1257769894.4680.313.camel@localhost> On Fri, 2009-11-06 at 01:13 +0100, Niklas Broberg wrote: > > Can someone please comment on these two proposed changes. I agree with > > Niklas but I'm a bit reluctant to apply the patches without at least > > some sign of agreement from someone else. > > > > Deprecating PatternSignatures seems uncontroversial, but the > > NoMonoPatBinds is potentially controversial. GHC essentially uses > > -XMonoPatBinds by default, even in H98 mode, and the user can use > > -XNoMonoPatBinds to restore H98 behaviour. Niklas's and my point is that > > the list of language extensions in Language.Haskell.Exceptions are > > differences from H98 so it should be MonoPatBinds to get the difference > > not NoMonoPatBinds to restore H98. > > > > In practise, since ghc uses MonoPatBinds by default it'd mean that > > people who want to get back to H98 would need to use: > > > > ghc-options: -XNoMonoPatBinds > > > > Because the extensions field is additive, not subtractive. Using the > > name MonoPatBinds allows other compilers to implement it without it > > having to be the default. > > I had a look at the source for cabal HEAD and was surprised to see > that this stuff had fallen by the wayside. What's holding it up? I > can't imagine that anyone would be against the deprecation of > PatternSignatures at least. I'd forgotten they were separate patches. I've applied the PatternSignatures one since that is indeed uncontroversial. I don't think the discussion on the other ones were conclusive yet. I think in the end I'm with Ian on his suggestion that we should allow the "No" prefix to invert an extension. This would help in this case and also let us handle things better when the default extensions change. Duncan From rl at cse.unsw.edu.au Mon Nov 9 08:02:37 2009 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Mon Nov 9 07:38:33 2009 Subject: seq as type class method In-Reply-To: References: Message-ID: <4FCF548F-F321-4D77-B6F0-761AE0630BC1@cse.unsw.edu.au> On 06/11/2009, at 09:50, Henning Thielemann wrote: > Actually in stream-fusion:Data.Stream I found such a class, called > Unlifted. How about moving this into a separate package? > > > class Unlifted a where > > -- | This expose function needs to be called in folds/loops that > consume > -- streams to expose the structure of the stream state to the > simplifier > -- In particular, to SpecConstr. > -- > expose :: a -> b -> b > expose = seq > > -- | This makes GHC's optimiser happier; it sometimes produces > really bad > -- code for single-method dictionaries > -- > unlifted_dummy :: a > unlifted_dummy = error "unlifted_dummy" This class serves as a vehicle for performing certain black magic rituals which (usually) help SpecConstr destroy evil artifacts introduced by stream fusion. In particular, expose is *not* seq; it is essentially deepSeq. As to single-method dictionaries, that problem existed two years or so ago. I don't think it still happens today. Roman From lemming at henning-thielemann.de Mon Nov 9 08:56:12 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Nov 9 08:29:52 2009 Subject: seq as type class method In-Reply-To: <4FCF548F-F321-4D77-B6F0-761AE0630BC1@cse.unsw.edu.au> References: <4FCF548F-F321-4D77-B6F0-761AE0630BC1@cse.unsw.edu.au> Message-ID: <4AF81F7C.9050004@henning-thielemann.de> Roman Leshchinskiy schrieb: > On 06/11/2009, at 09:50, Henning Thielemann wrote: > >> Actually in stream-fusion:Data.Stream I found such a class, called >> Unlifted. How about moving this into a separate package? >> >> >> class Unlifted a where >> >> -- | This expose function needs to be called in folds/loops that consume >> -- streams to expose the structure of the stream state to the simplifier >> -- In particular, to SpecConstr. >> -- >> expose :: a -> b -> b >> expose = seq >> >> -- | This makes GHC's optimiser happier; it sometimes produces really >> bad >> -- code for single-method dictionaries >> -- >> unlifted_dummy :: a >> unlifted_dummy = error "unlifted_dummy" > > This class serves as a vehicle for performing certain black magic > rituals which (usually) help SpecConstr destroy evil artifacts > introduced by stream fusion. In particular, expose is *not* seq; it is > essentially deepSeq. Mysteriously it seems there is also no deepseq package on Hackage ... only a DeepSeq module as part of HXT. Ok, there is Control.Parallel.Strategies.rnf, but I do not see, why deep strictness should be bound to the parallelism package (that is probably not as portable as a deep strictness package). http://www.haskell.org/pipermail/haskell-cafe/2006-October/019026.html From ganesh.sittampalam at credit-suisse.com Mon Nov 9 09:00:14 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Mon Nov 9 08:36:32 2009 Subject: seq as type class method In-Reply-To: <4AF81F7C.9050004@henning-thielemann.de> References: <4FCF548F-F321-4D77-B6F0-761AE0630BC1@cse.unsw.edu.au> <4AF81F7C.9050004@henning-thielemann.de> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B03B9FC6B@ELON17P32001A.csfb.cs-group.com> Henning Thielemann wrote: > Roman Leshchinskiy schrieb: >> On 06/11/2009, at 09:50, Henning Thielemann wrote: >>> expose :: a -> b -> b >>> expose = seq >>> >> This class serves as a vehicle for performing certain black magic >> rituals which (usually) help SpecConstr destroy evil artifacts >> introduced by stream fusion. In particular, expose is *not* seq; it >> is essentially deepSeq. > > Mysteriously it seems there is also no deepseq package on Hackage ... > only a DeepSeq module as part of HXT. > > Ok, there is Control.Parallel.Strategies.rnf, but I do not see, why > deep strictness should be bound to the parallelism package (that is > probably not as portable as a deep strictness package). > > http://www.haskell.org/pipermail/haskell-cafe/2006-October/019026.html I mentioned the idea of splitting out the strictness bits from parallel into a separate package a while ago and noone objected, but it needs someone to write the patch checking for hidden gotchas and make a formal proposal. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From niklas.broberg at gmail.com Mon Nov 9 09:19:36 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Mon Nov 9 08:55:30 2009 Subject: Three patches for cabal In-Reply-To: <1257769894.4680.313.camel@localhost> References: <1245230688.13502.2939.camel@localhost> <1257769894.4680.313.camel@localhost> Message-ID: > I think in the end I'm with Ian on his suggestion that we should allow > the "No" prefix to invert an extension. This would help in this case and > also let us handle things better when the default extensions change. I too agree with this position for the long run. /Niklas From duncan.coutts at googlemail.com Mon Nov 9 11:41:10 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon Nov 9 11:19:13 2009 Subject: seq as type class method In-Reply-To: References: <59543203684B2244980D7E4057D5FBC1061C08F8@DB3EX14MBXC310.europe.corp.microsoft.com> <404396ef0911090332m621a659br3cf5bb74f4648d83@mail.gmail.com> Message-ID: <1257784870.4680.621.camel@localhost> On Mon, 2009-11-09 at 12:19 +0000, Henning Thielemann wrote: > On Mon, 9 Nov 2009, Neil Mitchell wrote: > > >> | -- | This makes GHC's optimiser happier; it sometimes produces really bad > >> | -- code for single-method dictionaries > >> | -- > >> | unlifted_dummy :: a > >> | unlifted_dummy = error "unlifted_dummy" > >> > >> If you have such cases, please please boil it down and file it as a bug. We should get *better* code not worse for > >> single-method dictionaries. > > > > I benchmarked this when doing the Uniplate work - 1-member classes > > gave a noticeable performance benefit over 2 or more members. I think > > it was 6% or so in my setup, and as a result Uniplate has a single > > member type class. > > I assume the case in stream-fusion:Data.Stream was vice versa: A one > member class seemed to make performance worse .Thus they added a dummy > method. I believe Roman reported the problem at the time and I think that it got fixed. Duncan From ekmett at gmail.com Tue Nov 10 14:03:12 2009 From: ekmett at gmail.com (Edward Kmett) Date: Tue Nov 10 13:39:00 2009 Subject: Proposal: System.FilePath: current directory should be ".", not "" In-Reply-To: <404396ef0911051236r58cab85dt1cf19fa316eec048@mail.gmail.com> References: <4AB75CCE.1060709@gmail.com> <1253634191.18961.3032.camel@localhost> <4ABA2006.7010809@gmail.com> <1253812808.18961.6288.camel@localhost> <4AF150A1.3040403@gmail.com> <1257333109.25369.2555.camel@localhost> <404396ef0911051236r58cab85dt1cf19fa316eec048@mail.gmail.com> Message-ID: <7fb8f82f0911101103t20d1a129iacc5e83eba237b36@mail.gmail.com> +1 On Thu, Nov 5, 2009 at 3:36 PM, Neil Mitchell wrote: > I agree with the idea behind this proposal, but am pretty sure it will > break quite a few filepath things that I maintain. So +1, but also +1 > for a really strong release announcement and version bump. > > The problem with filepaths is that they lack much structure, and are > very system dependent - meaning every change will break something. A > lovely abstract type would be wonderful, but no one has yet released > such a library on hackage... > > Thanks, Neil > > > 2009/11/4 Duncan Coutts : > > On Wed, 2009-11-04 at 10:00 +0000, Simon Marlow wrote: > > > >> I've amended the patch as suggested above, it turned out to be not too > >> hard. > > > > [..] > > > >> Neil's comprehensive test suite still passes with the new patch. > >> > >> Ticket, with new patch attached: > >> > >> http://hackage.haskell.org/trac/ghc/ticket/2034 > >> > >> The discussion deadline has long passed, so I propose we have another 2 > >> weeks (18 November). > > > > I support this new proposal. > > > > > > To summarise for people who have not been paying full attention: > > > > Currently: > > takeDirectory "Main.hs" = "" > > > > Proposed: > > takeDirectory "Main.hs" = "./" > > > > The purpose being that one can always take the directory and get a valid > > path to use with a file system function, eg createDirectory. > > > > > > Unchanged behaviour: > > > > "./" "Main.hs" = "./Main.hs" > > > > It was initially proposed that eat "./" on the left hand side but > > the current proposal leaves the behaviour of unchanged. > > > > Duncan > > > > _______________________________________________ > > Libraries mailing list > > Libraries@haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > > _______________________________________________ > 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/20091110/5fd563a1/attachment.html From qdunkan at gmail.com Wed Nov 11 20:46:56 2009 From: qdunkan at gmail.com (Evan Laforge) Date: Wed Nov 11 20:22:42 2009 Subject: Data.Map/Data.IntMap additional features In-Reply-To: References: Message-ID: <2518b95d0911111746y6581e744v5fa5b8109e31ff5d@mail.gmail.com> On Tue, Nov 3, 2009 at 6:00 PM, Louis Wasserman wrote: >> but if it were a choice between findMax and >> extractWithKey with some Applicative and Monoid and whatever else >> magic, I'd use findMax every time :) I'd be wary of putting anything >> difficult to describe in a default interface for a basic data type. > > Okay, some restatement required here: I'm suggesting this method only for > Data.Map and Data.IntMap -- not for anything more common -- and I'm not by > any means suggesting that I'd use this in every case over findMin, but > merely using findMin as an example application.? I do think it's okay for a > commonly used module to have some advanced methods for advanced users. Sure, that's totally reasonable. > In the list of methods you named as particularly critical, you talked about > creating, inserting, updating, and deleting; you actually didn't mention > looking up values, which I assume you meant to -- since what's the point of > the map if you can't look up any values?? extractWithKey is useful when I > want to look up a value, and edit it, at the same time, without an exra > O(log n) pass, and it specifically and elegantly takes care of the case > where we want to simultaneously look up and edit the minimum or maximum > value of a map. Well ok I'm sold then, sign me up :) One other thing I haven't seen much reference too that I think could be a big win, and that's unboxed maps. A map in the vein of storablevector than can pack together a lot of elements in chunks, but keep persistence and log lookup with some shallow tree structure could be quite handy. I've heard clojure's arrays and maps are constructed along these lines. From ben_moseley at mac.com Sat Nov 14 07:42:02 2009 From: ben_moseley at mac.com (Ben Moseley) Date: Sat Nov 14 07:17:52 2009 Subject: Proposal: System.FilePath: current directory should be ".", not "" In-Reply-To: <404396ef0911051236r58cab85dt1cf19fa316eec048@mail.gmail.com> References: <4AB75CCE.1060709@gmail.com> <1253634191.18961.3032.camel@localhost> <4ABA2006.7010809@gmail.com> <1253812808.18961.6288.camel@localhost> <4AF150A1.3040403@gmail.com> <1257333109.25369.2555.camel@localhost> <404396ef0911051236r58cab85dt1cf19fa316eec048@mail.gmail.com> Message-ID: > A lovely abstract type would be wonderful, but no one has yet > released > such a library on hackage... I'm certainly not going to claim it's 'lovely' ... but there is now on hackage a library which offers an abstract type: http://hackage.haskell.org/package/pathtype It's very early days, hasn't been used in anger, doesn't support a lot of Windows things yet, but the basics do work. I'd be grateful for any comments (and of course patches!) Oh, and.... *System.Path> takeDirectory ("Main.hs"::RelFile) . --Ben On 5 Nov 2009, at 20:36, Neil Mitchell wrote: > I agree with the idea behind this proposal, but am pretty sure it will > break quite a few filepath things that I maintain. So +1, but also +1 > for a really strong release announcement and version bump. > > The problem with filepaths is that they lack much structure, and are > very system dependent - meaning every change will break something. A > lovely abstract type would be wonderful, but no one has yet released > such a library on hackage... > > Thanks, Neil > > > 2009/11/4 Duncan Coutts : >> On Wed, 2009-11-04 at 10:00 +0000, Simon Marlow wrote: >> >>> I've amended the patch as suggested above, it turned out to be not >>> too >>> hard. >> >> [..] >> >>> Neil's comprehensive test suite still passes with the new patch. >>> >>> Ticket, with new patch attached: >>> >>> http://hackage.haskell.org/trac/ghc/ticket/2034 >>> >>> The discussion deadline has long passed, so I propose we have >>> another 2 >>> weeks (18 November). >> >> I support this new proposal. >> >> >> To summarise for people who have not been paying full attention: >> >> Currently: >> takeDirectory "Main.hs" = "" >> >> Proposed: >> takeDirectory "Main.hs" = "./" >> >> The purpose being that one can always take the directory and get a >> valid >> path to use with a file system function, eg createDirectory. >> >> >> Unchanged behaviour: >> >> "./" "Main.hs" = "./Main.hs" >> >> It was initially proposed that eat "./" on the left hand side but >> the current proposal leaves the behaviour of unchanged. >> >> Duncan >> >> _______________________________________________ >> Libraries mailing list >> Libraries@haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From duncan.coutts at googlemail.com Sat Nov 14 09:02:27 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Sat Nov 14 08:38:08 2009 Subject: Proposal: System.FilePath: current directory should be ".", not "" In-Reply-To: References: <4AB75CCE.1060709@gmail.com> <1253634191.18961.3032.camel@localhost> <4ABA2006.7010809@gmail.com> <1253812808.18961.6288.camel@localhost> <4AF150A1.3040403@gmail.com> <1257333109.25369.2555.camel@localhost> <404396ef0911051236r58cab85dt1cf19fa316eec048@mail.gmail.com> Message-ID: <1258207347.4680.15794.camel@localhost> On Sat, 2009-11-14 at 12:42 +0000, Ben Moseley wrote: > > A lovely abstract type would be wonderful, but no one has yet > > released > > such a library on hackage... > > > I'm certainly not going to claim it's 'lovely' ... but there is now on > hackage a library which offers an abstract type: > > http://hackage.haskell.org/package/pathtype > > It's very early days, hasn't been used in anger, doesn't support a lot > of Windows things yet, but the basics do work. Great. > I'd be grateful for any comments (and of course patches!) So the type distinctions you are making are: * whether a path refers to a file or to a directory * whether a path is relative or absolute By relative and absolute it looks like you mean whether it starts with the root "/" vs not. So "foo/bar.txt" and "./foo/bar.txt" are both considered as relative. Yes? > Oh, and.... > > *System.Path> takeDirectory ("Main.hs"::RelFile) > . :-) So in the similar design I was working on, instead of distinguishing relative and absolute, I distinguish incomplete and complete. I initially started with the relative/absolute distinction and moved onto this one. It'd be interesting to see which is most useful in practise. What I mean by complete is a path referring to an actual file/dir that you could pass to a system call. This means they are anchored to some point the system knows about, such a "." the current directory or "/" or "C:\". Then an incomplete path is one that is not anchored. Incomplete paths become complete by them to a existing complete one (including the current dir). So the difference between this complete/incomplete notion and relative/absolute is for paths that are relative to the current directory. You would say "Main.hs" :: RelFile and readFile :: AbsRelClass ar => FilePath ar -> IO String and so readFile "Main.hs" is ok, and reads the file "./Main.hs" in the current directory. I would probably say, "Main.hs" :: IncompleteFilePath (though I think I used somewhat shorter type names than that!) and readFile :: CompleteFilePath -> IO String and thus readFile "Main.hs" is not well typed, instead it would be: readFile (currentDir "Main.hs") because that gives us a complete path, and if we want that to be rooted at the processes' current directory, then we do so explicitly. My intuition with file paths in Cabal, is that this distinction would catch more bugs. Ideally cabal's building code would be independent of the current directory, but the fact that relative paths get automagically completed to being relative to the current directory means that it's very easy to break this property. The type distinction would enforce it, and you could see explicitly where paths are deliberately completed relative to the current directory (or some other root). On the other hand it doesn't quite align with people's notion of relative paths so people might hate it :-). There are various other distinctions one could try to make, the question becomes which type distinctions are useful and when does it just become too much. For example one could distinguish file names (with no directory part), or pure roots with no directory part (eg ".", "/", "C: \", "//server/share/"). Duncan From ben_moseley at mac.com Sat Nov 14 12:50:19 2009 From: ben_moseley at mac.com (Ben Moseley) Date: Sat Nov 14 12:26:00 2009 Subject: Proposal: System.FilePath: current directory should be ".", not "" In-Reply-To: <1258207347.4680.15794.camel@localhost> References: <4AB75CCE.1060709@gmail.com> <1253634191.18961.3032.camel@localhost> <4ABA2006.7010809@gmail.com> <1253812808.18961.6288.camel@localhost> <4AF150A1.3040403@gmail.com> <1257333109.25369.2555.camel@localhost> <404396ef0911051236r58cab85dt1cf19fa316eec048@mail.gmail.com> <1258207347.4680.15794.camel@localhost> Message-ID: On 14 Nov 2009, at 14:02, Duncan Coutts wrote: > So the type distinctions you are making are: > > * whether a path refers to a file or to a directory > * whether a path is relative or absolute Yep, that's the idea. > By relative and absolute it looks like you mean whether it starts with > the root "/" vs not. So "foo/bar.txt" and "./foo/bar.txt" are both > considered as relative. Yes. > So in the similar design I was working on, instead of distinguishing > relative and absolute, I distinguish incomplete and complete. I > initially started with the relative/absolute distinction and moved > onto > this one. It'd be interesting to see which is most useful in practise. > > What I mean by complete is a path referring to an actual file/dir that > you could pass to a system call. This means they are anchored to some > point the system knows about, such a "." the current directory or > "/" or > "C:\". > > Then an incomplete path is one that is not anchored. Incomplete paths > become complete by them to a existing complete one (including the > current dir). > > So the difference between this complete/incomplete notion and > relative/absolute is for paths that are relative to the current > directory. > > You would say "Main.hs" :: RelFile > > and > > readFile :: AbsRelClass ar => FilePath ar -> IO String > > and so readFile "Main.hs" is ok, and reads the file "./Main.hs" in the > current directory. > > I would probably say, "Main.hs" :: IncompleteFilePath > > (though I think I used somewhat shorter type names than that!) > > and > > readFile :: CompleteFilePath -> IO String > > and thus readFile "Main.hs" is not well typed, instead it would be: > > readFile (currentDir "Main.hs") > > because that gives us a complete path, and if we want that to be > rooted > at the processes' current directory, then we do so explicitly. Ah, ok, I see. I can see the attraction to that. > My intuition with file paths in Cabal, is that this distinction would > catch more bugs. Ideally cabal's building code would be independent of > the current directory, but the fact that relative paths get > automagically completed to being relative to the current directory > means > that it's very easy to break this property. Interesting. One possible approach with pathtype as it stands would be a wrapper module which hides "readFile :: AbsRelClass ar => FilePath ar -> IO String" and exposes it only at the restricted type: "readAbsFile :: AbsFile -> IO String; readAbsFile = readFile". This blocks accidental reading of relative files and clients are forced to use something like 'makeAbsoluteFromCwd'. I don't think this is exactly the same as what you're suggesting (it doesn't permit the "completion" process to be separated from the reading), but I think it would be a way to catch some of the same bugs? > There are various other distinctions one could try to make, the > question > becomes which type distinctions are useful and when does it just > become > too much. I think this is a very important point. It's definitely a balancing act. I have ondered whether even capturing Abs/Rel was overkill, but my current feeling (not yet based on much real-world experience) is that it is worth it. Cheers, --Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20091114/4ac96081/attachment-0001.html From valery.vv at gmail.com Sat Nov 14 17:52:33 2009 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Sat Nov 14 17:28:10 2009 Subject: [patch] #562: cabal-install update fails going through a HTTP proxy In-Reply-To: <4AFF2AC3.8020403@gmail.com> References: <87ab0rc475.fsf@gmail.com> <1253319466.32005.432.camel@localhost> <4AB487F0.5040207@gmail.com> <4AFF2AC3.8020403@gmail.com> Message-ID: On Sun, Nov 15, 2009 at 12:10 AM, Sigbjorn Finne wrote: > > I've got a tentative fix in for this, not disabling closing altogether (that > wouldn't be compliant with Connection:close handling), but delaying > it until EOF is reached...at least that's the intent. It may not be lazy > enough, but I'm unable to verify either way right now. > > If anyone's interested in testing, the repo contains the changes made -- > > ?git://code.galois.com/HTTPbis.git/ Thanks, Sigbjorn! I'll test it this Monday (by running `cabal update' with new HTTP). -- vvv From allbery at ece.cmu.edu Sun Nov 15 17:01:59 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Nov 15 16:37:47 2009 Subject: Proposal: System.FilePath: current directory should be ".", not "" In-Reply-To: <1258207347.4680.15794.camel@localhost> References: <4AB75CCE.1060709@gmail.com> <1253634191.18961.3032.camel@localhost> <4ABA2006.7010809@gmail.com> <1253812808.18961.6288.camel@localhost> <4AF150A1.3040403@gmail.com> <1257333109.25369.2555.camel@localhost> <404396ef0911051236r58cab85dt1cf19fa316eec048@mail.gmail.com> <1258207347.4680.15794.camel@localhost> Message-ID: <48FBE681-FA87-41AB-9100-01EB6BCDA278@ece.cmu.edu> On Nov 14, 2009, at 09:02 , Duncan Coutts wrote: > On the other hand it doesn't quite align with people's notion of > relative paths so people might hate it :-). Seems to me this approach handles Windows better. There is no single "current directory"; it's one per drive letter (plus one for "default", which might not be a drive letter if you "cd" to a UNC path). It also handles building paths for processes launched somewhere not the current directory, which seems like a big win to me. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/libraries/attachments/20091115/2cd995cd/PGP.bin From duncan.coutts at googlemail.com Sun Nov 15 19:47:43 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Sun Nov 15 19:23:19 2009 Subject: Advance warning to package authors of breakage Message-ID: <1258332463.4896.1545.camel@localhost> package authors, I'm preparing to release two new versions of cabal-install. The following packages are broken, and the new cabal-install releases will mean that more users run into the breakage than do so currently. All these packages claim to work with base 3 *and* with base 4, however they actually only work with base 3. The new cabal-install will build them against base 4 and so users will notice that they are broken. I'm emailing the whole libs list because while I was able to build most of hackage, I could not build all of it, so there may be other packages with this same problem. FileManipCompat-0.14 type-level-0.2.3 compact-string-0.3.1 ghc-core-0.5 hsmtpclient-1.0 pointful-1.0.1 show-0.3.3 These packages all use "build-depends: base >= 3 && < 4" (except for ghc-core which cheekily uses "build-depends: base < 10" --- a practise we will ban if it becomes any more popular). Current versions of cabal-install choose base version 3 in this case, the new cabal-install will choose base version 4 in this case. The reason for the somewhat odd current behaviour was to help with packages that only said "build-depends: >=3". Now that we require an upper bound too, the new behaviour is to only apply the backwards compat preferences for version ranges that are unbounded above. For ones that are bounded above we go back to picking the highest version by default. Duncan From duncan.coutts at googlemail.com Sun Nov 15 20:46:48 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Sun Nov 15 20:22:23 2009 Subject: Advance warning to package authors of breakage In-Reply-To: <1258332463.4896.1545.camel@localhost> References: <1258332463.4896.1545.camel@localhost> Message-ID: <1258336008.4896.1665.camel@localhost> On Mon, 2009-11-16 at 00:47 +0000, Duncan Coutts wrote: > These packages all use "build-depends: base >= 3 && < 4" Sorry, typo. Of course that should have been: "build-depends: base >= 3 && < 5" > Current versions of cabal-install choose base version 3 in this case, > the new cabal-install will choose base version 4 in this case. With the typo fix above this bit is now true. :-) Sorry for the confusion. Duncan From svein.ove at aas.no Sun Nov 15 21:49:22 2009 From: svein.ove at aas.no (Svein Ove Aas) Date: Sun Nov 15 21:24:55 2009 Subject: Advance warning to package authors of breakage In-Reply-To: <1258332463.4896.1545.camel@localhost> References: <1258332463.4896.1545.camel@localhost> Message-ID: <221b53ab0911151849h3dbc5683hc31016c955f87ba0@mail.gmail.com> On Mon, Nov 16, 2009 at 1:47 AM, Duncan Coutts wrote: > package authors, > > I'm preparing to release two new versions of cabal-install. > Does this new version happen to work with the GHC 6.12 release candidate? -- Svein Ove Aas From wren at community.haskell.org Mon Nov 16 03:20:38 2009 From: wren at community.haskell.org (wren ng thornton) Date: Mon Nov 16 02:56:13 2009 Subject: Proposal: System.FilePath: current directory should be ".", not "" In-Reply-To: <4B00F744.3060105@freegeek.org> References: <4AB75CCE.1060709@gmail.com> <1253634191.18961.3032.camel@localhost> <4ABA2006.7010809@gmail.com> <1253812808.18961.6288.camel@localhost> <4AF150A1.3040403@gmail.com> <1257333109.25369.2555.camel@localhost> <404396ef0911051236r58cab85dt1cf19fa316eec048@mail.gmail.com> <1258207347.4680.15794.camel@localhost> <4B00F744.3060105@freegeek.org> Message-ID: <4B010B56.9010706@community.haskell.org> Ben Moseley wrote: > Duncan Coutts wrote: >> My intuition with file paths in Cabal, is that this distinction would >> catch more bugs. Ideally cabal's building code would be independent of >> the current directory, but the fact that relative paths get >> automagically completed to being relative to the current directory means >> that it's very easy to break this property. > > [...] > >> There are various other distinctions one could try to make, the question >> becomes which type distinctions are useful and when does it just become >> too much. > > I think this is a very important point. It's definitely a balancing > act. I have > ondered whether even capturing Abs/Rel was overkill, but my current > feeling > (not yet based on much real-world experience) is that it is worth it. Having done a lot of system administration and metaprogramming of system administration, I can certainly say that making the relative/absolute distinction is helpful for tracking down bugs. From the same set of experience I'd say that Duncan's incomplete/complete distinction would be even more helpful. With a lot of sysadmin metaprogramming (which includes package installers) what people are really working on is grafting different trees together. It's important to distinguish which paths/trees are being created and don't yet refer to an actual or potential file on the disk, from those paths/trees which refer to actual/potential files on the disk. To think about why this distinction is helpful, consider where all we may want to attach the paths/trees we're creating. The two obvious places are / and . but there are other options too. Most programs support some notion of a $PATH variable or allow flags to specify the target directory for reading or writing. With the complete/incomplete distinction we distinguish names which aren't yet grounded from names that refer to files, regardless of where they're mounted. With the relative/absolute distinction we don't know when a path is finished being constructed, and we also have no real vocabulary for expressing paths relative from some point other than the current directory. Most sysadmins don't seem to realize they're doing tree grafting when they mess with this stuff, so I can see why it might seem foreign, but viewing it that way really does help clean code up and find bugs. Tree grafting also forms a monad, which could be helpful for some folks. -- Live well, ~wren From valery.vv at gmail.com Mon Nov 16 06:02:39 2009 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Mon Nov 16 05:38:12 2009 Subject: [patch] #562: cabal-install update fails going through a HTTP proxy In-Reply-To: References: <87ab0rc475.fsf@gmail.com> <1253319466.32005.432.camel@localhost> <4AB487F0.5040207@gmail.com> <4AFF2AC3.8020403@gmail.com> Message-ID: > On Sun, Nov 15, 2009 at 12:10 AM, Sigbjorn Finne > wrote: >> >> I've got a tentative fix in for this, not disabling closing altogether (that >> wouldn't be compliant with Connection:close handling), but delaying0 >> it until EOF is reached...at least that's the intent. It may not be lazy >> enough, but I'm unable to verify either way right now. >> >> If anyone's interested in testing, the repo contains the changes made -- >> >> git://code.galois.com/HTTPbis.git/ On Sun, Nov 15, 2009 at 12:52 AM, Valery V. Vorotyntsev wrote: > Thanks, Sigbjorn! > > I'll test it this Monday (by running `cabal update' with new HTTP). Sorry, Sigbjorn, it didn't work. I've installed HTTP-4000.0.9 (the git version) and rebuilt-reinstalled cabal-install with it. The problem persist: $ cabal update Downloading the latest package list from hackage.haskell.org cabal: Codec.Compression.Zlib: premature end of compressed stream $ $ runhaskell proxy-POC.hs Content-Length: 1304519 bytes downloaded: 2408 proxy-POC.hs: user error (sizes differ) I've rolled back to patched HTTP-4000.0.8, the one with connection closing commented out in `sendHTTP_notify'. I need this proxy downloading thing to just work... * * * AFAIU, you cannot test HTTP operation over proxy server, can you? I'm not sure, but installing squid might help exposing the bug. And if you let me speculate a bit... What if we employ ByteString's hGetContents for reading from connection? `hGetContents' closes handle automatically upon reaching EOF[1]. And ByteString does buffering by itself, HTTP package would not need as many {read,write}Block, buffer{Get,Put}Block calls[2] as there are now. The code would be simpler with fewer places for our current bug to hide. [1] http://is.gd/4W9sp [2] http://is.gd/4W97Y This is just an idea, nothing more. -- Regards, vvv From the.dead.shall.rise at gmail.com Mon Nov 16 06:31:23 2009 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Mon Nov 16 06:06:54 2009 Subject: Fwd: Advance warning to package authors of breakage In-Reply-To: <3cb898890911160328h41576174yd7d4d9f4e1100ca8@mail.gmail.com> References: <1258332463.4896.1545.camel@localhost> <3cb898890911160328h41576174yd7d4d9f4e1100ca8@mail.gmail.com> Message-ID: <3cb898890911160331jb00efc5x287e7ed63dd5318b@mail.gmail.com> Hi, On Mon, Nov 16, 2009 at 1:47 AM, Duncan Coutts wrote: > > These packages all use "build-depends: base >= 3 && < 5" (except for > ghc-core which cheekily uses "build-depends: base < 10" --- a practise > we will ban if it becomes any more popular). I have one question. It looks like the recommended way to solve the problem is to use something like: Flag separateSYB ?Description: Data.Generics available in separate package. [...] ? ?if flag(separateSYB) ? ? ? build-Depends: base >= 3 && < 4 ? ?else ? ? ? build-Depends: base >= 4 && < 5, syb When the user types 'cabal install pointful' (without providing -fseparateSYB), which version of base will be the executable built against? -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From duncan.coutts at googlemail.com Mon Nov 16 07:37:19 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon Nov 16 07:12:53 2009 Subject: Advance warning to package authors of breakage In-Reply-To: <221b53ab0911151849h3dbc5683hc31016c955f87ba0@mail.gmail.com> References: <1258332463.4896.1545.camel@localhost> <221b53ab0911151849h3dbc5683hc31016c955f87ba0@mail.gmail.com> Message-ID: <1258375039.4896.2971.camel@localhost> On Mon, 2009-11-16 at 03:49 +0100, Svein Ove Aas wrote: > On Mon, Nov 16, 2009 at 1:47 AM, Duncan Coutts > wrote: > > package authors, > > > > I'm preparing to release two new versions of cabal-install. > > > Does this new version happen to work with the GHC 6.12 release candidate? Version 0.8 will do (the current darcs 0.7.5 works with it already). Version 0.6.4 may or may not, depending on how difficult it is to hack it. If it does, it'll probably only work well enough to let you "cabal install cabal-install" and will probably prompt you to do so frequently. If not, then it'll just break with a better error message. Duncan From duncan.coutts at googlemail.com Mon Nov 16 07:41:30 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon Nov 16 07:17:04 2009 Subject: Advance warning to package authors of breakage In-Reply-To: <3cb898890911160328h41576174yd7d4d9f4e1100ca8@mail.gmail.com> References: <1258332463.4896.1545.camel@localhost> <3cb898890911160328h41576174yd7d4d9f4e1100ca8@mail.gmail.com> Message-ID: <1258375290.4896.2984.camel@localhost> On Mon, 2009-11-16 at 12:28 +0100, Mikhail Glushenkov wrote: > Hi, > > On Mon, Nov 16, 2009 at 1:47 AM, Duncan Coutts > wrote: > > > > These packages all use "build-depends: base >= 3 && < 5" (except for > > ghc-core which cheekily uses "build-depends: base < 10" --- a practise > > we will ban if it becomes any more popular). > > I have one question. It looks like the recommended way to solve the > problem is to use something like: > > Flag separateSYB > Description: Data.Generics available in separate package. > > [...] > if flag(separateSYB) > build-Depends: base >= 3 && < 4 > else > build-Depends: base >= 4 && < 5, syb > > When the user types 'cabal install pointful' (without providing > -fseparateSYB), which version of base will be the executable built > against? It prefers the default value of the flag. If that's impossible then it tries with the non-default flag value. When you do not specify a default flag value, the default is True. So as you've written it, in the absence of any constraints it'll pick the separateSYB=True configuration, which as you've written it, will *not* use the separate syb package. I think you intended to write it the other way around. Duncan From valery.vv at gmail.com Mon Nov 16 09:19:43 2009 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Mon Nov 16 08:55:15 2009 Subject: #562: cabal-install update fails going through a HTTP proxy In-Reply-To: <4B01531E.8050804@gmail.com> References: <87ab0rc475.fsf@gmail.com> <1253319466.32005.432.camel@localhost> <4AB487F0.5040207@gmail.com> <4AFF2AC3.8020403@gmail.com> <4B01531E.8050804@gmail.com> Message-ID: On Mon, Nov 16, 2009 at 3:26 PM, Sigbjorn Finne wrote: > Thanks - that's good, now we know :) ?I suspect tempering the notion of > close and doing > a socket shutdown is the way forward here. I'll see if I can play with this > some tonight. Good luck with that! :) -- vvv From ben_moseley at mac.com Mon Nov 16 14:16:37 2009 From: ben_moseley at mac.com (Ben Moseley) Date: Mon Nov 16 13:52:11 2009 Subject: Proposal: System.FilePath: current directory should be ".", not "" In-Reply-To: <4B010B56.9010706@community.haskell.org> References: <4AB75CCE.1060709@gmail.com> <1253634191.18961.3032.camel@localhost> <4ABA2006.7010809@gmail.com> <1253812808.18961.6288.camel@localhost> <4AF150A1.3040403@gmail.com> <1257333109.25369.2555.camel@localhost> <404396ef0911051236r58cab85dt1cf19fa316eec048@mail.gmail.com> <1258207347.4680.15794.camel@localhost> <4B00F744.3060105@freegeek.org> <4B010B56.9010706@community.haskell.org> Message-ID: Thanks for the comments - I'll look at incorporating them into pathtype. (I've taken the liberty of filing this along with Duncan's comments as: http://trac.haskell.org/pathtype/ticket/2). --Ben On 16 Nov 2009, at 08:20, wren ng thornton wrote: > Ben Moseley wrote: >> Duncan Coutts wrote: >>> My intuition with file paths in Cabal, is that this distinction >>> would >>> catch more bugs. Ideally cabal's building code would be >>> independent of >>> the current directory, but the fact that relative paths get >>> automagically completed to being relative to the current directory >>> means >>> that it's very easy to break this property. >> >> [...] >> >>> There are various other distinctions one could try to make, the >>> question >>> becomes which type distinctions are useful and when does it just >>> become >>> too much. >> >> I think this is a very important point. It's definitely a balancing >> act. I have >> ondered whether even capturing Abs/Rel was overkill, but my current >> feeling >> (not yet based on much real-world experience) is that it is worth it. > > Having done a lot of system administration and metaprogramming of > system > administration, I can certainly say that making the relative/absolute > distinction is helpful for tracking down bugs. From the same set of > experience I'd say that Duncan's incomplete/complete distinction would > be even more helpful. > > With a lot of sysadmin metaprogramming (which includes package > installers) what people are really working on is grafting different > trees together. It's important to distinguish which paths/trees are > being created and don't yet refer to an actual or potential file on > the > disk, from those paths/trees which refer to actual/potential files on > the disk. > > To think about why this distinction is helpful, consider where all we > may want to attach the paths/trees we're creating. The two obvious > places are / and . but there are other options too. Most programs > support some notion of a $PATH variable or allow flags to specify the > target directory for reading or writing. With the complete/incomplete > distinction we distinguish names which aren't yet grounded from names > that refer to files, regardless of where they're mounted. With the > relative/absolute distinction we don't know when a path is finished > being constructed, and we also have no real vocabulary for expressing > paths relative from some point other than the current directory. > > Most sysadmins don't seem to realize they're doing tree grafting when > they mess with this stuff, so I can see why it might seem foreign, but > viewing it that way really does help clean code up and find bugs. Tree > grafting also forms a monad, which could be helpful for some folks. > > -- > Live well, > ~wren > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From duncan.coutts at googlemail.com Mon Nov 16 14:45:37 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon Nov 16 14:21:10 2009 Subject: Proposal: System.FilePath: current directory should be ".", not "" In-Reply-To: <4B010B56.9010706@community.haskell.org> References: <4AB75CCE.1060709@gmail.com> <1253634191.18961.3032.camel@localhost> <4ABA2006.7010809@gmail.com> <1253812808.18961.6288.camel@localhost> <4AF150A1.3040403@gmail.com> <1257333109.25369.2555.camel@localhost> <404396ef0911051236r58cab85dt1cf19fa316eec048@mail.gmail.com> <1258207347.4680.15794.camel@localhost> <4B00F744.3060105@freegeek.org> <4B010B56.9010706@community.haskell.org> Message-ID: <1258400737.4896.4217.camel@localhost> On Mon, 2009-11-16 at 03:20 -0500, wren ng thornton wrote: > To think about why this distinction is helpful, consider where all we > may want to attach the paths/trees we're creating. The two obvious > places are / and . but there are other options too. Most programs > support some notion of a $PATH variable or allow flags to specify the > target directory for reading or writing. This is a good point. Once you've got a search $PATH of some sort then "./foo" and "foo" are actually different. "./foo" is a complete path and refers to the file (or directory) foo in the current directory while "foo" is an incomplete path that the function will try to complete by looking for a file in each of the search directories. So under a complete/incomplete distinction, a function like exec takes Either Complete Incomplete, where the incomplete ones get the search path treatment and the complete ones do not. Duncan From valery.vv at gmail.com Mon Nov 16 16:15:59 2009 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Mon Nov 16 15:51:29 2009 Subject: [patch] #562: cabal-install update fails going through a HTTP proxy In-Reply-To: <4B01531E.8050804@gmail.com> References: <87ab0rc475.fsf@gmail.com> <1253319466.32005.432.camel@localhost> <4AB487F0.5040207@gmail.com> <4AFF2AC3.8020403@gmail.com> <4B01531E.8050804@gmail.com> Message-ID: > Valery V. Vorotyntsev wrote: >> Sorry, Sigbjorn, it didn't work. Sigbjorn Finne wrote: > Thanks - that's good, now we know :) I'm not so sure any more. >> I've rolled back to patched HTTP-4000.0.8, the one with connection >> closing commented out in `sendHTTP_notify'. I need this proxy >> downloading thing to just work... Cabal client reinstalled with "patched" HTTP-4000.0.8 was still having occasional failures today. My proxy-POC.hs always succeeded, while cabal failed quite often with familiar cabal: Codec.Compression.Zlib: premature end of compressed stream This means that proxy-POC.hs is not trustworthy: it doesn't expose the bug in 100% cases. I am going to roll back even further tomorrow: I'll patch [1] cabal-install to use strict ByteStrings and see if /that/ does the job. (I'm not sure in anything any more.) [1] http://hpaste.org/fastcgi/hpaste.fcgi/view?id=9447#a9504 > I suspect tempering the notion of close and doing a socket shutdown > is the way forward here. So do I... If my suspicions are of any significance after several delusive "Wolf!" cries [2,3]. [2] http://hackage.haskell.org/trac/hackage/ticket/562#comment:9 [3] http://trac.haskell.org/http/ticket/8#comment:7 > I'll see if I can play with this some tonight. I've installed squid proxy server. Gotta make this bug exposable... -- Regards, vvv From valery.vv at gmail.com Mon Nov 16 17:21:13 2009 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Mon Nov 16 16:56:43 2009 Subject: [patch] #562: cabal-install update fails going through a HTTP proxy In-Reply-To: <4B01CC93.6090602@gmail.com> References: <87ab0rc475.fsf@gmail.com> <4AFF2AC3.8020403@gmail.com> <4B01531E.8050804@gmail.com> <4B01C3D6.2080502@gmail.com> <4B01CC93.6090602@gmail.com> Message-ID: > Valery V. Vorotyntsev wrote: >> Could you please notify me, if you make any commits tomorrow in day time? >> >> git port is not accessible for me in working hours: the proxied LAN allows >> outbound connection to 80 and 443 ports only. But when I know there are >> new commits, I'll establish GPRS connection and download 'em. Sigbjorn Finne wrote: > Certainly, but no immediate plans to do so -- you can see repo updates via > http://code.galois.com/ > (and subscribe to feeds to be notified that way.) Oh, I didn't know about these feeds. Thanks! > It'd be nice if code.galois allowed clone/pulls via http.. It would be, yes. Only few sites seem to care. I start to wonder, whether proxied [office] LANs are so rare nowadays? :) -- vvv From valery.vv at gmail.com Mon Nov 16 18:15:34 2009 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Mon Nov 16 17:51:05 2009 Subject: Could iteratee depend on mtl instead of transformers? Message-ID: Hi, Iteratee [1] library depends on transformers [2]. The latter exposes `Control.Monad.Trans' module. [1] http://hackage.haskell.org/package/iteratee-0.3.1 [2] http://hackage.haskell.org/package/transformers-0.1.4.0 So does mtl [3] which is also installed on my system. [3] http://hackage.haskell.org/package/mtl-1.1.0.2 As a result, I cannot compile a program using Data.Iteratee, unless one of the packages is hidden. $ ghci GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> :m + Control.Monad.Trans Could not find module `Control.Monad.Trans': it was found in multiple packages: mtl-1.1.0.2 transformers-0.1.4.0 $ ghci hide transformers-0.1.4.0 Having transformers hidden, I need to copy-paste MonadTrans and MonadIO instances [4] from Data.Iteratee.Base to my code, otherwise I get errors: Prelude> :load "/home/vvv/job/cdr.mscp/Codec/Binary/MSCP.hs" [1 of 1] Compiling Codec.Binary.MSCP ( /home/vvv/job/cdr.mscp/Codec/Binary/MSCP.hs, interpreted ) /home/vvv/job/cdr.mscp/Codec/Binary/MSCP.hs:88:7: Could not deduce (MonadIO (IterateeG [] Word8 m)) from the context (MonadIO m) arising from a use of `liftIO' at /home/vvv/job/cdr.mscp/Codec/Binary/MSCP.hs:88:7-12 Possible fix: add (MonadIO (IterateeG [] Word8 m)) to the context of the type signature for `warn' or add an instance declaration for (MonadIO (IterateeG [] Word8 m)) In the first argument of `(.)', namely `liftIO' In the expression: liftIO . hPutStrLn stderr . ("*WARNING* " ++) In the definition of `warn': warn = liftIO . hPutStrLn stderr . ("*WARNING* " ++) Failed, modules loaded: none. [4] http://bit.ly/1TT37E With MonadTrans & MonadIO instances duplicated, I need to use `-fno-warn-orphans' GHC option in order not to see "orphan instance" warnings. Or I can just update iteratee.cabal and make it depend on mtl instead of transformers: --- iteratee.cabal.orig 2009-11-09 20:40:29.000000000 +0200 +++ iteratee.cabal 2009-11-16 18:32:36.637288144 +0200 @@ -59,7 +59,7 @@ containers >= 0.2 && < 0.4, extensible-exceptions >= 0.1 && < 0.2, haskell98 >= 1 && < 2, - transformers >= 0.1.4 && < 0.2 + mtl >= 1.1 && < 1.2 exposed-modules: Data.Iteratee This allows me to remove Monad{Trans,IO} instances from my code and forget about `-fno-warn-orphans' flag. But now my package cannot claim its dependency on iteratee-0.3.1 any more. Thus, the question is: are there any transformers-specific features iteratee package needs, or can it just go with mtl? * * * I suspect mtl to be more popular... And actual "popularity" can be measured. I'll try to do that using cabal-query [5] tool; it allows to list "reverse dependencies" [6]. [5] http://hackage.haskell.org/package/cabal-query [6] http://hackage.haskell.org/trac/hackage/ticket/576#comment:2 Cheers. -- vvv From mle+hs at mega-nerd.com Mon Nov 16 20:42:08 2009 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Mon Nov 16 20:17:38 2009 Subject: Could iteratee depend on mtl instead of transformers? In-Reply-To: References: Message-ID: <20091117124208.ffeb0a35.mle+hs@mega-nerd.com> Valery V. Vorotyntsev wrote: > Thus, the question is: are there any transformers-specific features > iteratee package needs, or can it just go with mtl? I have successful build iteratee by replacing transformers with mtl in the .cabal file. > I suspect mtl to be more popular... And actual "popularity" can be > measured. Popularity is not the issue. The issue is that we are currently in a transition from using mtl to using transformers. See: http://www.haskell.org/pipermail/libraries/2009-March/011415.html http://www.haskell.org/pipermail/haskell-cafe/2009-October/067744.html Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From ekmett at gmail.com Mon Nov 16 23:03:01 2009 From: ekmett at gmail.com (Edward Kmett) Date: Mon Nov 16 22:38:30 2009 Subject: Could iteratee depend on mtl instead of transformers? In-Reply-To: <20091117124208.ffeb0a35.mle+hs@mega-nerd.com> References: <20091117124208.ffeb0a35.mle+hs@mega-nerd.com> Message-ID: <7fb8f82f0911162003x6ec712caw8c2c4f7a53dc0680@mail.gmail.com> On Mon, Nov 16, 2009 at 8:42 PM, Erik de Castro Lopo > wrote: > Valery V. Vorotyntsev wrote: > > > Thus, the question is: are there any transformers-specific features > > iteratee package needs, or can it just go with mtl? > > I have successful build iteratee by replacing transformers with > mtl in the .cabal file. > > > I suspect mtl to be more popular... And actual "popularity" can be > > measured. > > Popularity is not the issue. The issue is that we are currently > in a transition from using mtl to using transformers. See: > > http://www.haskell.org/pipermail/libraries/2009-March/011415.html > http://www.haskell.org/pipermail/haskell-cafe/2009-October/067744.html > > Are we? The first thread starts off cheering for monads-fd/tf and transformers, but fizzles out, as people consider the impact of breaking existing software. The other one is a post by Ganesh, which for all I know could be a statement of his personal position and seems less than authoritative as to the direction of the Haskell Platform as a whole. Perhaps I missed the memo, or perhaps I am just unclear as to which antecedent 'we' refers to in your statement. In any event, I don't mean this to sound nearly as confrontational as it probably does, but I didn't get the impression from either the initial thread or its brief resurgence that anything had been decided. -Edward Kmett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20091116/cd372b05/attachment.html From nicolas.pouillard at gmail.com Tue Nov 17 03:19:50 2009 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Tue Nov 17 02:55:18 2009 Subject: Could iteratee depend on mtl instead of transformers? In-Reply-To: <7fb8f82f0911162003x6ec712caw8c2c4f7a53dc0680@mail.gmail.com> References: <20091117124208.ffeb0a35.mle+hs@mega-nerd.com> <7fb8f82f0911162003x6ec712caw8c2c4f7a53dc0680@mail.gmail.com> Message-ID: <1258445961-sup-4987@peray> Excerpts from Edward Kmett's message of Tue Nov 17 05:03:01 +0100 2009: > On Mon, Nov 16, 2009 at 8:42 PM, Erik de Castro Lopo > > > wrote: > > > Valery V. Vorotyntsev wrote: > > > > > Thus, the question is: are there any transformers-specific features > > > iteratee package needs, or can it just go with mtl? > > > > I have successful build iteratee by replacing transformers with > > mtl in the .cabal file. > > > > > I suspect mtl to be more popular... And actual "popularity" can be > > > measured. > > > > Popularity is not the issue. The issue is that we are currently > > in a transition from using mtl to using transformers. See: > > > > http://www.haskell.org/pipermail/libraries/2009-March/011415.html > > http://www.haskell.org/pipermail/haskell-cafe/2009-October/067744.html > > > > > Are we? Let's make a poll then! transformers+1 -- Nicolas Pouillard http://nicolaspouillard.fr From johan.tibell at gmail.com Tue Nov 17 03:32:16 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue Nov 17 03:08:04 2009 Subject: Could iteratee depend on mtl instead of transformers? In-Reply-To: <1258445961-sup-4987@peray> References: <20091117124208.ffeb0a35.mle+hs@mega-nerd.com> <7fb8f82f0911162003x6ec712caw8c2c4f7a53dc0680@mail.gmail.com> <1258445961-sup-4987@peray> Message-ID: <90889fe70911170032w35a697d4x28cfd9a057f83865@mail.gmail.com> On Tue, Nov 17, 2009 at 9:19 AM, Nicolas Pouillard wrote: > Excerpts from Edward Kmett's message of Tue Nov 17 05:03:01 +0100 2009: >> On Mon, Nov 16, 2009 at 8:42 PM, Erik de Castro Lopo >> >> > Popularity is not the issue. The issue is that we are currently >> > in a transition from using mtl to using transformers. See: >> > >> > ? http://www.haskell.org/pipermail/libraries/2009-March/011415.html >> > ? http://www.haskell.org/pipermail/haskell-cafe/2009-October/067744.html >> > >> > >> Are we? > > Let's make a poll then! I went back and reread the two linked threads and I'm no wiser as to why we should prefer transformers. I'd like to see an argument describing the benefits of using transformers vs the drawbacks (including how much code would break). -- Johan From ganesh.sittampalam at credit-suisse.com Tue Nov 17 04:11:27 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Tue Nov 17 03:47:26 2009 Subject: Could iteratee depend on mtl instead of transformers? In-Reply-To: <90889fe70911170032w35a697d4x28cfd9a057f83865@mail.gmail.com> References: <20091117124208.ffeb0a35.mle+hs@mega-nerd.com><7fb8f82f0911162003x6ec712caw8c2c4f7a53dc0680@mail.gmail.com> <1258445961-sup-4987@peray> <90889fe70911170032w35a697d4x28cfd9a057f83865@mail.gmail.com> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B03B9FCB7@ELON17P32001A.csfb.cs-group.com> Johan Tibell wrote: > I went back and reread the two linked threads and I'm no wiser as to > why we should prefer transformers. The key point of transformers is that mtl is approximately the same as the combination of transformers + monads-fd - where transformers is H98, and monads-fd has the functional dependency based type classes (MonadState etc). So making the split means that only code that actually needs those classes need depend on them. Since the future of fundeps is up in the air, this seems like a better position to be in. It also enables people to use monads-tf (i.e. type family based classes) without using an incompatible set of transformer types (which is what mtl-tf contains). > I'd like to see an argument > describing the benefits of using transformers vs the drawbacks > (including how much code would break). Migration would be by releasing mtl-2.0 which re-exports transformers + monads-fd. There are a few changes in transformers compared to mtl which clean up the design but at the cost of breaking backwards compatibility - one prominent example is that Functor instances in the transformer types now depend on Functor instances in the base types, where as mtl has them depending on Monad instances. Another change (which isn't crucial to the migration) is to replace the currently separate State, Reader etc types with type synonyms to StateT Identity, ReaderT Identity etc. http://www.haskell.org/pipermail/libraries/2009-March/011471.html roughly summarises how much of hackage would break as of then (March 09). I haven't had time to rerun the experiment recently, which is one reason I haven't made a formal proposal yet. I also think that I didn't do anything to test packages that follow the PVP and thus wouldn't have picked up the newer mtl due to having an upper bound on their mtl dependency. Of course such well-behaved packages won't break immediately but will need code changes at some point to be brought up to date. None of the compilation problems are hard to fix, as far as I know. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From marlowsd at gmail.com Tue Nov 17 06:00:21 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Nov 17 05:36:07 2009 Subject: ANNOUNCE: deepseq-1.0.0.0 Message-ID: <4B028245.1080201@gmail.com> I've just uploaded deepseq-1.0.0.0 to Hackage http://hackage.haskell.org/package/deepseq This provides a DeepSeq class with a deepseq method, equivalent to the existing NFData/rnf in the parallel package. I'll be using this in a newly revamped parallel package, which I hope to upload shortly. Cheers, Simon From lemming at henning-thielemann.de Tue Nov 17 05:59:56 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Nov 17 05:36:17 2009 Subject: Could iteratee depend on mtl instead of transformers? In-Reply-To: References: Message-ID: On Tue, 17 Nov 2009, Valery V. Vorotyntsev wrote: > Thus, the question is: are there any transformers-specific features > iteratee package needs, or can it just go with mtl? The question is, whether Iteratee needs functions of MTL that transformers does not provide? 'Transformers' is the more basic package, entirely Haskell 98, thus should be prefered. It is however sad, that Transformers cannot easily be used with GHCi in parallel with MTL installed. I was always against that ... Renaming Control.Monad.Trans and Control.Monad.Identity to something else would solve the conflict. I'm also not happy, that you have to choose between monads-fd and monads-tf. I think it would be better to be able to have both type class approaches. From vandijk.roel at gmail.com Tue Nov 17 06:04:37 2009 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Tue Nov 17 05:40:05 2009 Subject: [Haskell-cafe] ANNOUNCE: deepseq-1.0.0.0 In-Reply-To: <4B028245.1080201@gmail.com> References: <4B028245.1080201@gmail.com> Message-ID: On Tue, Nov 17, 2009 at 12:00 PM, Simon Marlow wrote: > I've just uploaded deepseq-1.0.0.0 to Hackage This is great! I often use rnf to fully evaluate some expression where I didn't need parallelism at all. Time to update some packages. Thank you, Roel From duncan.coutts at googlemail.com Tue Nov 17 06:16:47 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Tue Nov 17 05:52:19 2009 Subject: Could iteratee depend on mtl instead of transformers? In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B03B9FCB7@ELON17P32001A.csfb.cs-group.com> References: <20091117124208.ffeb0a35.mle+hs@mega-nerd.com> <7fb8f82f0911162003x6ec712caw8c2c4f7a53dc0680@mail.gmail.com> <1258445961-sup-4987@peray> <90889fe70911170032w35a697d4x28cfd9a057f83865@mail.gmail.com> <16442B752A06A74AB4D9F9A5FF076E4B03B9FCB7@ELON17P32001A.csfb.cs-group.com> Message-ID: <1258456607.4896.7125.camel@localhost> On Tue, 2009-11-17 at 09:11 +0000, Sittampalam, Ganesh wrote: > > I'd like to see an argument > > describing the benefits of using transformers vs the drawbacks > > (including how much code would break). > > Migration would be by releasing mtl-2.0 which re-exports transformers + > monads-fd. There are a few changes in transformers compared to mtl which > clean up the design but at the cost of breaking backwards compatibility > - one prominent example is that Functor instances in the transformer > types now depend on Functor instances in the base types, where as mtl > has them depending on Monad instances. Another change (which isn't > crucial to the migration) is to replace the currently separate State, > Reader etc types with type synonyms to StateT Identity, ReaderT Identity > etc. > > http://www.haskell.org/pipermail/libraries/2009-March/011471.html > roughly summarises how much of hackage would break as of then (March > 09). I haven't had time to rerun the experiment recently, which is one > reason I haven't made a formal proposal yet. I also think that I didn't > do anything to test packages that follow the PVP and thus wouldn't have > picked up the newer mtl due to having an upper bound on their mtl > dependency. Of course such well-behaved packages won't break immediately > but will need code changes at some point to be brought up to date. We can use hackage and the platform to help manage the transition too. So I don't think it's necessary to go for a minimally breaking design. My opinion is you should go for whatever you can all agree is the best design, and then we manage the transition. I suggest that the strategy should be to: * decide what the best "new" monad library should be (consensus between the various monad package authors and other experts) * play with it as much as possible first to work out the kinks * adjust hackage to make old packages not break by using a preference on mtl < 2 * adjust hackage to require new packages use an upper bound on mtl, indicating if they're compatible with mtl-2 or not * release mtl-2 * once the experts are happy with mtl-2, to include it into the next Haskell Platform release and encourage everyone to switch over. For example, the next platform release will use QC2 and that should help resolve the problem we have now where half the packages are still using QC1 (since that was the version that shipped with ghc and the previous HP release). Duncan From jpm at cs.uu.nl Tue Nov 17 06:16:57 2009 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Tue Nov 17 05:52:54 2009 Subject: [Haskell-cafe] ANNOUNCE: deepseq-1.0.0.0 In-Reply-To: References: <4B028245.1080201@gmail.com> Message-ID: <52f14b210911170316t3257d84el97494704fc213d29@mail.gmail.com> Hello, The release of the regular library for generic programming on Hackage [1] also contains a form of deep seq [2]. This means that you don't even have to write the definition of 'deepseq', you can just use 'gdseq' (assuming you have used Template Haskell to derive the generic representations for your types). Cheers, Pedro [1] http://hackage.haskell.org/package/regular [2] http://hackage.haskell.org/packages/archive/regular/0.2.1/doc/html/Generics-Regular-Functions-Seq.html#t%3ASeq On Tue, Nov 17, 2009 at 12:04, Roel van Dijk wrote: > On Tue, Nov 17, 2009 at 12:00 PM, Simon Marlow wrote: >> I've just uploaded deepseq-1.0.0.0 to Hackage > > This is great! I often use rnf to fully evaluate some expression where > I didn't need parallelism at all. Time to update some packages. > > Thank you, > Roel > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From valery.vv at gmail.com Tue Nov 17 06:22:48 2009 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Tue Nov 17 05:58:17 2009 Subject: Could iteratee depend on mtl instead of transformers? In-Reply-To: References: Message-ID: Henning Thielemann wrote: > The question is, whether Iteratee needs functions of MTL that > transformers does not provide? 'Transformers' is the more basic > package, entirely Haskell 98, thus should be prefered. It is however > sad, that Transformers cannot easily be used with GHCi in parallel > with MTL installed. I was always against that ... Renaming > Control.Monad.Trans and Control.Monad.Identity to something else > would solve the conflict. I'm also not happy, that you have to > choose between monads-fd and monads-tf. I think it would be better > to be able to have both type class approaches. Is there a way to tell GHCi ``Take Control.Monad.Trans from mtl package for this session'' or ``Use transformers this time'' without updating ghc-pkg config file (hide/expose)? If there is none, do you think inventing one would be a good idea? -- vvv From lemming at henning-thielemann.de Tue Nov 17 06:35:05 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Nov 17 06:10:33 2009 Subject: Could iteratee depend on mtl instead of transformers? In-Reply-To: References: Message-ID: On Tue, 17 Nov 2009, Valery V. Vorotyntsev wrote: > Is there a way to tell GHCi ``Take Control.Monad.Trans from mtl > package for this session'' or ``Use transformers this time'' without > updating ghc-pkg config file (hide/expose)? > > If there is none, do you think inventing one would be a good idea? With 'ghc-pkg hide' and 'expose' you can set your general preference. With '-hide-package mtl' and '-package transformers' you can choose per invokation of GHCi. From mle+hs at mega-nerd.com Tue Nov 17 06:54:01 2009 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Tue Nov 17 06:29:31 2009 Subject: Could iteratee depend on mtl instead of transformers? In-Reply-To: References: Message-ID: <20091117225401.5bf3f3a3.mle+hs@mega-nerd.com> Henning Thielemann wrote: > The question is, whether Iteratee needs functions of MTL that transformers > does not provide? For both the last version 0.2.4 and the current version 0.3.1, transformers can be replaced with MTL and still result in a working iteratee package. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From nicolas.pouillard at gmail.com Tue Nov 17 07:25:14 2009 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Tue Nov 17 07:00:46 2009 Subject: [Haskell-cafe] ANNOUNCE: deepseq-1.0.0.0 In-Reply-To: <4B028245.1080201@gmail.com> References: <4B028245.1080201@gmail.com> Message-ID: <1258460604-sup-9104@peray> Excerpts from Simon Marlow's message of Tue Nov 17 12:00:21 +0100 2009: > I've just uploaded deepseq-1.0.0.0 to Hackage Great! I'm wondering what is the need/purpose for DeepSeqIntegral and DeepSeqOrd? -- Nicolas Pouillard http://nicolaspouillard.fr From michael at snoyman.com Tue Nov 17 07:56:44 2009 From: michael at snoyman.com (Michael Snoyman) Date: Tue Nov 17 07:32:12 2009 Subject: Could iteratee depend on mtl instead of transformers? In-Reply-To: <1258445961-sup-4987@peray> References: <20091117124208.ffeb0a35.mle+hs@mega-nerd.com> <7fb8f82f0911162003x6ec712caw8c2c4f7a53dc0680@mail.gmail.com> <1258445961-sup-4987@peray> Message-ID: <29bf512f0911170456h7871a981tc49560b936640c@mail.gmail.com> On Tue, Nov 17, 2009 at 10:19 AM, Nicolas Pouillard < nicolas.pouillard@gmail.com> wrote: > Excerpts from Edward Kmett's message of Tue Nov 17 05:03:01 +0100 2009: > > On Mon, Nov 16, 2009 at 8:42 PM, Erik de Castro Lopo > > > > > > > wrote: > > > > > Valery V. Vorotyntsev wrote: > > > > > > > Thus, the question is: are there any transformers-specific features > > > > iteratee package needs, or can it just go with mtl? > > > > > > I have successful build iteratee by replacing transformers with > > > mtl in the .cabal file. > > > > > > > I suspect mtl to be more popular... And actual "popularity" can be > > > > measured. > > > > > > Popularity is not the issue. The issue is that we are currently > > > in a transition from using mtl to using transformers. See: > > > > > > http://www.haskell.org/pipermail/libraries/2009-March/011415.html > > > > http://www.haskell.org/pipermail/haskell-cafe/2009-October/067744.html > > > > > > > > Are we? > > Let's make a poll then! > > transformers+1 FWIW, +1 transformers. I like being able to swap monads-fd and monads-tf. Michael > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20091117/0a924e89/attachment.html From p.k.f.holzenspies at utwente.nl Tue Nov 17 08:47:44 2009 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?ISO-8859-1?Q?H=F6lzenspies?=) Date: Tue Nov 17 08:23:13 2009 Subject: Proposal (Trac ticket #3671): Add takeRec, genericTakeRec and spanRec to Data.List Message-ID: <1258465664.2704.6.camel@ewi1043> Dear all, After defining these for the umpeenth time, I would like to add the functions takeRec, genericTakeRec and spanRec to Data.List, as per http://hackage.haskell.org/trac/ghc/ticket/3671 Suggested discussion time: 2 weeks. Regards, Philip From duncan.coutts at googlemail.com Tue Nov 17 09:00:58 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Tue Nov 17 08:36:32 2009 Subject: ANNOUNCE: deepseq-1.0.0.0 In-Reply-To: <4B028245.1080201@gmail.com> References: <4B028245.1080201@gmail.com> Message-ID: <1258466458.4896.7785.camel@localhost> On Tue, 2009-11-17 at 11:00 +0000, Simon Marlow wrote: > I've just uploaded deepseq-1.0.0.0 to Hackage > > http://hackage.haskell.org/package/deepseq > > This provides a DeepSeq class with a deepseq method, equivalent to the > existing NFData/rnf in the parallel package. I'll be using this in a > newly revamped parallel package, which I hope to upload shortly. Yay, you get to be the first person to try out the new platform package proposal process! http://trac.haskell.org/haskell-platform/wiki/AddingPackages (because it's a new dependency of a platform package) Duncan From ekmett at gmail.com Tue Nov 17 09:09:07 2009 From: ekmett at gmail.com (Edward Kmett) Date: Tue Nov 17 08:44:39 2009 Subject: Could iteratee depend on mtl instead of transformers? In-Reply-To: <29bf512f0911170456h7871a981tc49560b936640c@mail.gmail.com> References: <20091117124208.ffeb0a35.mle+hs@mega-nerd.com> <7fb8f82f0911162003x6ec712caw8c2c4f7a53dc0680@mail.gmail.com> <1258445961-sup-4987@peray> <29bf512f0911170456h7871a981tc49560b936640c@mail.gmail.com> Message-ID: <7fb8f82f0911170609r3bc24d82ic771e395ed414d72@mail.gmail.com> -1 in their current form. I like that transformers is Haskell 98 and presents a common core. I think that factoring it out is a laudable goal. However, my very problem is that monads-fd and monads-tf are mutually incompatible. It fragments the community of monad combinator users even further. If monads-fd sat in the existing location of mtl or was exported there by an mtl compatibility layer and monads-tf used a different namespace then you would have a clean solution in which both could be used in the same code, because both could be loaded. As it is, all that is done is we will go through all the trouble of breaking a lot of existing code, only to have to make a decision about which half of the code we broke we want to break again later once the community slides towards monads-fd or monads-tf or more likely stagnates in indecision between them. In the meantime there is no right answer for library authors who want to be able to support both. If this is the direction we want to go, I don't see how we could conscionably make the choice to change without making it so that monads-fd and monads-tf can both be loaded by the same program, lest we find ourselves having this very discussion again in 6 months. -Edward Kmett On Tue, Nov 17, 2009 at 7:56 AM, Michael Snoyman wrote: > > > On Tue, Nov 17, 2009 at 10:19 AM, Nicolas Pouillard < > nicolas.pouillard@gmail.com> wrote: > >> Excerpts from Edward Kmett's message of Tue Nov 17 05:03:01 +0100 2009: >> > On Mon, Nov 16, 2009 at 8:42 PM, Erik de Castro Lopo >> > >> > >> > > wrote: >> > >> > > Valery V. Vorotyntsev wrote: >> > > >> > > > Thus, the question is: are there any transformers-specific features >> > > > iteratee package needs, or can it just go with mtl? >> > > >> > > I have successful build iteratee by replacing transformers with >> > > mtl in the .cabal file. >> > > >> > > > I suspect mtl to be more popular... And actual "popularity" can be >> > > > measured. >> > > >> > > Popularity is not the issue. The issue is that we are currently >> > > in a transition from using mtl to using transformers. See: >> > > >> > > http://www.haskell.org/pipermail/libraries/2009-March/011415.html >> > > >> http://www.haskell.org/pipermail/haskell-cafe/2009-October/067744.html >> > > >> > > >> > Are we? >> >> Let's make a poll then! >> >> transformers+1 > > > FWIW, +1 transformers. I like being able to swap monads-fd and monads-tf. > > Michael > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20091117/4cb8a741/attachment-0001.html From igloo at earth.li Tue Nov 17 09:35:17 2009 From: igloo at earth.li (Ian Lynagh) Date: Tue Nov 17 09:11:04 2009 Subject: Proposal (Trac ticket #3671): Add takeRec, genericTakeRec and spanRec to Data.List In-Reply-To: <1258465664.2704.6.camel@ewi1043> References: <1258465664.2704.6.camel@ewi1043> Message-ID: <20091117143517.GA443@matrix.chaos.earth.li> Hi Philip, On Tue, Nov 17, 2009 at 02:47:44PM +0100, Philip K.F. H?lzenspies wrote: > > After defining these for the umpeenth time, I would like to add the > functions takeRec, genericTakeRec and spanRec to Data.List, as per > > http://hackage.haskell.org/trac/ghc/ticket/3671 I don't think spanRec does what you want: take 10 $ spanRec (< 3) [1,2,3,4,5,6,1,2,3,4,5,6] [[1,2],[],[],[],[],[],[],[],[],[]] I have also defined your "takeRec" a number of times in the past, but I have called it something like "splitAts". I've also defined functions called "breaks". I think the 's' suffix is more consistent with "tails", "inits" etc. Thanks Ian From valery.vv at gmail.com Tue Nov 17 09:42:58 2009 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Tue Nov 17 09:18:26 2009 Subject: Could iteratee depend on mtl instead of transformers? In-Reply-To: References: Message-ID: > Valery V. Vorotyntsev wrote: > >> Is there a way to tell GHCi ``Take Control.Monad.Trans from mtl >> package for this session'' or ``Use transformers this time'' without >> updating ghc-pkg config file (hide/expose)? Henning Thielemann wrote: > With 'ghc-pkg hide' and 'expose' you can set your general preference. With > '-hide-package mtl' and '-package transformers' you can choose per > invokation of GHCi. ``When you say import A.B.C, from what package does A.B.C come?'' I've found [*] a hackage wiki page devoted to this question: http://hackage.haskell.org/trac/ghc/wiki/GhcPackages#Theopenquestion [*] I just tried to add `-hide-package mtl' to OPTIONS_GHC pragma, with no success, and was googling for a clue. Prelude> :load "/home/vvv/job/cdr.mscp/Codec/Binary/MSCP.hs" /home/vvv/job/cdr.mscp/Codec/Binary/MSCP.hs:1:15-39: unknown flag in {-# OPTIONS #-} pragma: -hide-package /home/vvv/job/cdr.mscp/Codec/Binary/MSCP.hs:1:15-39: unknown flag in {-# OPTIONS #-} pragma: mtl > -- vvv From p.k.f.holzenspies at utwente.nl Tue Nov 17 10:11:21 2009 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?ISO-8859-1?Q?H=F6lzenspies?=) Date: Tue Nov 17 09:46:57 2009 Subject: Proposal (Trac ticket #3671): Add takeRec, genericTakeRec and spanRec to Data.List In-Reply-To: <20091117143517.GA443@matrix.chaos.earth.li> References: <1258465664.2704.6.camel@ewi1043> <20091117143517.GA443@matrix.chaos.earth.li> Message-ID: <1258470681.2704.16.camel@ewi1043> On Tue, 2009-11-17 at 14:35 +0000, Ian Lynagh wrote: > > http://hackage.haskell.org/trac/ghc/ticket/3671 > > I don't think spanRec does what you want: > > take 10 $ spanRec (< 3) [1,2,3,4,5,6,1,2,3,4,5,6] > [[1,2],[],[],[],[],[],[],[],[],[]] > > I have also defined your "takeRec" a number of times in the past, but I > have called it something like "splitAts". I've also defined functions > called "breaks". I think the 's' suffix is more consistent with "tails", > "inits" etc. Dear Ian, et al. I posted the proposal too quickly. Two corrections and *still* missed it. I should have dug up my PreludeEx from somewhere. You are right about the mistake, though. Also, I also usually use the 's' suffix, but thought it could possibly be considered too invasive in the namespace. If no one objects to +s names, then I actually prefer it. When also including spans antonym 'breaks', they can actually be defined in mutually recursive fashion. Thus, the new proposal: splitAts :: Int -> [a] -> [[a]] splitAts = genericSplitAts genericSplitAts :: (Integral a) => a -> [b] -> [[b]] genericSplitAts n _ | n <= 0 = [] genericSplitAts _ [] = [] genericSplitAts i xs = let (hs,ts) = genericSplitAt i xs in hs : genericSplitAts i ts spans :: (a -> Bool) -> [a] -> [[a]] spans _ [] = [] spans p xs = let (hs,ts) = span p xs in hs : breaks p ts breaks :: (a -> Bool) -> [a] -> [[a]] breaks _ [] = [] breaks p xs = let (hs,ts) = break p xs in hs : spans p ts Am I chalking you up as a +1? Regrads, Philip From jeremy at n-heptane.com Tue Nov 17 10:11:28 2009 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Tue Nov 17 09:47:00 2009 Subject: Could iteratee depend on mtl instead of transformers? In-Reply-To: References: Message-ID: <23520C53-A04C-44B1-960A-8C728465E749@n-heptane.com> On Nov 17, 2009, at 8:42 AM, Valery V. Vorotyntsev wrote: > > [*] I just tried to add `-hide-package mtl' to OPTIONS_GHC pragma, > with no success, and was googling for a clue. I don't think that works, but you can do: {-# LANGUAGE PackageImports #-} import "transformers" Control.Monad.Reader in GHC 6.10 and higher. I think you could even do: {-# LANGUAGE PackageImports #-} import "transformers" Control.Monad.Reader import "mtl" Control.Monad.Writer - jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20091117/3ccf24ec/attachment.html From valery.vv at gmail.com Tue Nov 17 10:23:31 2009 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Tue Nov 17 09:58:58 2009 Subject: Could iteratee depend on mtl instead of transformers? In-Reply-To: <23520C53-A04C-44B1-960A-8C728465E749@n-heptane.com> References: <23520C53-A04C-44B1-960A-8C728465E749@n-heptane.com> Message-ID: Jeremy Shaw wrote: > > I don't think that works, but you can do: > {-# LANGUAGE PackageImports #-} > import "transformers" Control.Monad.Reader > in GHC 6.10 and higher. I think you could even do: > > {-# LANGUAGE PackageImports #-} > import "transformers" Control.Monad.Reader > import "mtl" ? ? ? ? ? ? ? ? ?Control.Monad.Writer Yes, this works! Thanks, Jeremy. -- vvv From ross at soi.city.ac.uk Tue Nov 17 11:04:30 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Nov 17 10:39:45 2009 Subject: Could iteratee depend on mtl instead of transformers? In-Reply-To: <7fb8f82f0911170609r3bc24d82ic771e395ed414d72@mail.gmail.com> References: <20091117124208.ffeb0a35.mle+hs@mega-nerd.com> <7fb8f82f0911162003x6ec712caw8c2c4f7a53dc0680@mail.gmail.com> <1258445961-sup-4987@peray> <29bf512f0911170456h7871a981tc49560b936640c@mail.gmail.com> <7fb8f82f0911170609r3bc24d82ic771e395ed414d72@mail.gmail.com> Message-ID: <20091117160430.GA14545@soi.city.ac.uk> On Tue, Nov 17, 2009 at 09:09:07AM -0500, Edward Kmett wrote: > I like that transformers is Haskell 98 and presents a common core. I > think that factoring it out is a laudable goal. > > However, my very problem is that monads-fd and monads-tf are mutually > incompatible. It fragments the community of monad combinator users > even further. > > If monads-fd sat in the existing location of mtl or was exported there > by an mtl compatibility layer and monads-tf used a different namespace > then you would have a clean solution in which both could be used in > the same code, because both could be loaded. The proposal is to make the next version of mtl a near-compatibility layer over monads-fd and transformers; it doesn't involve monads-tf directly. We could just rename all the modules in monads-tf (which aimed to mirror mtl-tf), or perhaps rename the modules in both monads-fd and monads-tf. Perhaps we should trim both packages to just the class modules (the others are re-exports mirroring mtl) and relocate those in the module hierarchy: Control.Monad.Cont.Class Control.Monad.Error.Class Control.Monad.RWS.Class Control.Monad.Reader.Class Control.Monad.State.Class Control.Monad.Writer.Class They both have the same Cont class; it need not be duplicated. From bos at serpentine.com Tue Nov 17 11:36:47 2009 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue Nov 17 11:12:21 2009 Subject: [Haskell-cafe] ANNOUNCE: deepseq-1.0.0.0 In-Reply-To: <4B028245.1080201@gmail.com> References: <4B028245.1080201@gmail.com> Message-ID: On Tue, Nov 17, 2009 at 3:00 AM, Simon Marlow wrote: > I've just uploaded deepseq-1.0.0.0 to Hackage > > http://hackage.haskell.org/package/deepseq > > This provides a DeepSeq class with a deepseq method, equivalent to the > existing NFData/rnf in the parallel package. > > If it's equivalent, what are the relevant differences? Why would I choose DeepSeq over NFData or vice versa? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20091117/580f4fdf/attachment.html From allbery at ece.cmu.edu Tue Nov 17 13:42:52 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Nov 17 13:18:43 2009 Subject: [Haskell-cafe] ANNOUNCE: deepseq-1.0.0.0 In-Reply-To: References: <4B028245.1080201@gmail.com> Message-ID: <09552E18-4CAF-4C90-83E6-468631B90F31@ece.cmu.edu> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/libraries/attachments/20091117/b0f21666/PGP-0001.bin From ekmett at gmail.com Tue Nov 17 19:33:05 2009 From: ekmett at gmail.com (Edward Kmett) Date: Tue Nov 17 19:08:32 2009 Subject: Could iteratee depend on mtl instead of transformers? In-Reply-To: <20091117160430.GA14545@soi.city.ac.uk> References: <20091117124208.ffeb0a35.mle+hs@mega-nerd.com> <7fb8f82f0911162003x6ec712caw8c2c4f7a53dc0680@mail.gmail.com> <1258445961-sup-4987@peray> <29bf512f0911170456h7871a981tc49560b936640c@mail.gmail.com> <7fb8f82f0911170609r3bc24d82ic771e395ed414d72@mail.gmail.com> <20091117160430.GA14545@soi.city.ac.uk> Message-ID: <7fb8f82f0911171633l260390ddj221ef938474f3590@mail.gmail.com> For symmetry I agree both should probably be renamed. What are the current breaking changes? I gather from the discussion that State is no longer separate from StateT, along with Reader, Writer, RWS, Error, mutatis mutandis to obviate the need for both a base monad and transformer. I guess the question is then, when should code start looking to changing their dependencies over to monads-tf and monads-fd? A cleanly demarked cut over would be useful to get us out of this limbo state that helps nobody. -Edward Kmett On Tue, Nov 17, 2009 at 11:04 AM, Ross Paterson wrote: > On Tue, Nov 17, 2009 at 09:09:07AM -0500, Edward Kmett wrote: > > I like that transformers is Haskell 98 and presents a common core. I > > think that factoring it out is a laudable goal. > > > > However, my very problem is that monads-fd and monads-tf are mutually > > incompatible. It fragments the community of monad combinator users > > even further. > > > > If monads-fd sat in the existing location of mtl or was exported there > > by an mtl compatibility layer and monads-tf used a different namespace > > then you would have a clean solution in which both could be used in > > the same code, because both could be loaded. > > The proposal is to make the next version of mtl a near-compatibility layer > over monads-fd and transformers; it doesn't involve monads-tf directly. > We could just rename all the modules in monads-tf (which aimed to mirror > mtl-tf), or perhaps rename the modules in both monads-fd and monads-tf. > Perhaps we should trim both packages to just the class modules (the others > are re-exports mirroring mtl) and relocate those in the module hierarchy: > > Control.Monad.Cont.Class > Control.Monad.Error.Class > Control.Monad.RWS.Class > Control.Monad.Reader.Class > Control.Monad.State.Class > Control.Monad.Writer.Class > > They both have the same Cont class; it need not be duplicated. > _______________________________________________ > 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/20091117/177cb4e0/attachment.html From ross at soi.city.ac.uk Tue Nov 17 19:57:19 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Nov 17 19:32:29 2009 Subject: Could iteratee depend on mtl instead of transformers? In-Reply-To: <7fb8f82f0911171633l260390ddj221ef938474f3590@mail.gmail.com> References: <20091117124208.ffeb0a35.mle+hs@mega-nerd.com> <7fb8f82f0911162003x6ec712caw8c2c4f7a53dc0680@mail.gmail.com> <1258445961-sup-4987@peray> <29bf512f0911170456h7871a981tc49560b936640c@mail.gmail.com> <7fb8f82f0911170609r3bc24d82ic771e395ed414d72@mail.gmail.com> <20091117160430.GA14545@soi.city.ac.uk> <7fb8f82f0911171633l260390ddj221ef938474f3590@mail.gmail.com> Message-ID: <20091118005719.GA26862@soi.city.ac.uk> On Tue, Nov 17, 2009 at 07:33:05PM -0500, Edward Kmett wrote: > For symmetry I agree both should probably be renamed. Naming suggestions are welcome. Also comments on the idea of dropping the non-class modules from monads-*. > What are the current breaking changes? > > I gather from the discussion that State is no longer separate from > StateT, along with Reader, Writer, RWS, Error, mutatis mutandis to > obviate the need for both a base monad and transformer. Right, so modules that declare instances of State, etc, or use their data constructors, will break. In the former case the instances will in most cases become superfluous. Some packages declare orphan Applicative or Alternative instances, which will also become superfluous. The Functor instances in transformers depend on Functor rather than monad. The breakage can be fixed by adding functor instances. > I guess the question is then, when should code start looking to changing > their dependencies over to monads-tf and monads-fd? > > A cleanly demarked cut over would be useful to get us out of this limbo state > that helps nobody. According to Ganesh's survey, 17 packages (and their dependents) on hackage would be broken by turning mtl into a compatibility layer over transformers+monads-fd. They would need to be updated, but need not switch to monads-tf or monads-fd. Or they could avoid breakage by adding a dependency mtl < 2. Individual packages could switch to the new packages at their leisure. I agree that the current situation is problematic -- I think we should press on and replace the mtl. From aslatter at gmail.com Tue Nov 17 21:56:21 2009 From: aslatter at gmail.com (Antoine Latter) Date: Tue Nov 17 21:31:48 2009 Subject: Could iteratee depend on mtl instead of transformers? In-Reply-To: <7fb8f82f0911171633l260390ddj221ef938474f3590@mail.gmail.com> References: <20091117124208.ffeb0a35.mle+hs@mega-nerd.com> <7fb8f82f0911162003x6ec712caw8c2c4f7a53dc0680@mail.gmail.com> <1258445961-sup-4987@peray> <29bf512f0911170456h7871a981tc49560b936640c@mail.gmail.com> <7fb8f82f0911170609r3bc24d82ic771e395ed414d72@mail.gmail.com> <20091117160430.GA14545@soi.city.ac.uk> <7fb8f82f0911171633l260390ddj221ef938474f3590@mail.gmail.com> Message-ID: <694519c50911171856n68f9fbc3r1cdf9e6a8eeb4a64@mail.gmail.com> On Tue, Nov 17, 2009 at 6:33 PM, Edward Kmett wrote: > I gather from the discussion that State is no longer separate from StateT, > along with Reader, Writer, RWS, Error, mutatis mutandis to obviate the need > for both a base monad and transformer. Every time this comes up I grow paranoid that there is some sort of general overhead to evaluating an expression of type "StateT s Identity a" vs "State s a". So I finally benchmarked it using the example code listed in Control.Monad.State, and found no difference whatsoever. Here's the source: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=12259#a12259 I guess parsec is the odd one out, where there is a difference. Or I was measuring something else back when I had parsec benchmarks set up. Antoine From dan.doel at gmail.com Tue Nov 17 22:27:29 2009 From: dan.doel at gmail.com (Dan Doel) Date: Tue Nov 17 22:02:58 2009 Subject: Could iteratee depend on mtl instead of transformers? In-Reply-To: <694519c50911171856n68f9fbc3r1cdf9e6a8eeb4a64@mail.gmail.com> References: <7fb8f82f0911171633l260390ddj221ef938474f3590@mail.gmail.com> <694519c50911171856n68f9fbc3r1cdf9e6a8eeb4a64@mail.gmail.com> Message-ID: <200911172227.30004.dan.doel@gmail.com> On Tuesday 17 November 2009 9:56:21 pm Antoine Latter wrote: > Every time this comes up I grow paranoid that there is some sort of > general overhead to evaluating an expression of type "StateT s > Identity a" vs "State s a". > > So I finally benchmarked it using the example code listed in > Control.Monad.State, and found no difference whatsoever. > > Here's the source: > http://hpaste.org/fastcgi/hpaste.fcgi/view?id=12259#a12259 > > I guess parsec is the odd one out, where there is a difference. Or I > was measuring something else back when I had parsec benchmarks set up. At least in the State case, everything involved is a newtype, so: StateT s Identity a should be represented identically to: s -> Identity (a, s) = s -> (a, s) Which is exactly what State s a is. From there it's just up to the compiler to eliminate no-ops like: return :: a -> a -- return :: a -> Identity a return a = a which shouldn't be too arduous. Building up stacks of novel monads can introduce additional indirection over flattening them into a direct implementation (like StateT s (WriterT w ...) versus RWST r s w ...), but thankfully, Identity shouldn't introduce such overhead. -- Dan From heringtonlacey at mindspring.com Tue Nov 17 22:48:19 2009 From: heringtonlacey at mindspring.com (Dean Herington) Date: Tue Nov 17 22:24:01 2009 Subject: ANNOUNCE: deepseq-1.0.0.0 In-Reply-To: <4B028245.1080201@gmail.com> References: <4B028245.1080201@gmail.com> Message-ID: At 11:00 AM +0000 11/17/09, Simon Marlow wrote: >I've just uploaded deepseq-1.0.0.0 to Hackage > > http://hackage.haskell.org/package/deepseq > >This provides a DeepSeq class with a deepseq method, equivalent to >the existing NFData/rnf in the parallel package. I'll be using this >in a newly revamped parallel package, which I hope to upload shortly. > >Cheers, > Simon The documentation claim that "The default implementation of 'deepseq' is simply 'seq'" is not exactly right, as `deepseq` and `seq` have different signatures. Which raises the more interesting question: Why did you choose a different signature? And, would a version of `seq` with the same signature as `deepseq` be useful? Dean From malcolm.wallace at cs.york.ac.uk Tue Nov 17 23:05:34 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Nov 17 22:42:10 2009 Subject: [Haskell-cafe] Re: ANNOUNCE: deepseq-1.0.0.0 In-Reply-To: References: <4B028245.1080201@gmail.com> Message-ID: <4EAD957A-8BDC-4BFD-85D9-39B74D638556@cs.york.ac.uk> > The documentation claim that "The default implementation of > 'deepseq' is simply 'seq'" is not exactly right, as `deepseq` and > `seq` have different signatures. Yes indeed. In order to use deepseq, it looks like I also need some way to force the () return value, e.g. let res = deepseq (my big computation) in res `seq` use res or let res = deepseq (my big computation) in case res of () -> use res I suppose the advantage of this approach is to ensure that the user must let-bind the forced value to a name. A beginner might write (my big computation) `seq` use (my big computation) without realising that it fails to do what they desire. Regards, Malcolm From ganesh at earth.li Wed Nov 18 02:44:32 2009 From: ganesh at earth.li (Ganesh Sittampalam) Date: Wed Nov 18 02:19:58 2009 Subject: Could iteratee depend on mtl instead of transformers? In-Reply-To: <7fb8f82f0911171633l260390ddj221ef938474f3590@mail.gmail.com> References: <20091117124208.ffeb0a35.mle+hs@mega-nerd.com> <7fb8f82f0911162003x6ec712caw8c2c4f7a53dc0680@mail.gmail.com> <1258445961-sup-4987@peray> <29bf512f0911170456h7871a981tc49560b936640c@mail.gmail.com> <7fb8f82f0911170609r3bc24d82ic771e395ed414d72@mail.gmail.com> <20091117160430.GA14545@soi.city.ac.uk> <7fb8f82f0911171633l260390ddj221ef938474f3590@mail.gmail.com> Message-ID: On Tue, 17 Nov 2009, Edward Kmett wrote: > I guess the question is then, when should code start looking to changing > their dependencies over to monads-tf and monads-fd? > > A cleanly demarked cut over would be useful to get us out of this limbo > state that helps nobody. Are you suggesting that we declare a date or on which people should make the switch? I think that might make some sense if we weren't already accidentally part way through it, but given that we are, I'd say the best option is to just do it asap once there is proper agreement. Ganesh From marlowsd at gmail.com Wed Nov 18 03:53:31 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Nov 18 03:29:13 2009 Subject: [Haskell-cafe] ANNOUNCE: deepseq-1.0.0.0 In-Reply-To: <09552E18-4CAF-4C90-83E6-468631B90F31@ece.cmu.edu> References: <4B028245.1080201@gmail.com> <09552E18-4CAF-4C90-83E6-468631B90F31@ece.cmu.edu> Message-ID: <4B03B60B.6010104@gmail.com> On 17/11/2009 18:42, Brandon S. Allbery KF8NH wrote: > On Nov 17, 2009, at 11:36 , Bryan O'Sullivan wrote: >> On Tue, Nov 17, 2009 at 3:00 AM, Simon Marlow > > wrote: >> >> I've just uploaded deepseq-1.0.0.0 to Hackage >> >> http://hackage.haskell.org/package/deepseq >> >> This provides a DeepSeq class with a deepseq method, equivalent to >> the existing NFData/rnf in the parallel package. >> >> >> >> If it's equivalent, what are the relevant differences? Why would I >> choose DeepSeq over NFData or vice versa? > > Considering that he said he's going to be using it in parallel, the > difference is merely that it's usable *without* parallel. It's about > dependencies, not functionality. Yes, that's exactly it. No new functionality relative to NFData, just moving it to a more appropriate place. Cheers, Simon From marlowsd at gmail.com Wed Nov 18 03:55:28 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Nov 18 03:31:01 2009 Subject: [Haskell-cafe] ANNOUNCE: deepseq-1.0.0.0 In-Reply-To: <1258460604-sup-9104@peray> References: <4B028245.1080201@gmail.com> <1258460604-sup-9104@peray> Message-ID: <4B03B680.3060108@gmail.com> On 17/11/2009 12:25, Nicolas Pouillard wrote: > Excerpts from Simon Marlow's message of Tue Nov 17 12:00:21 +0100 2009: >> I've just uploaded deepseq-1.0.0.0 to Hackage > > Great! > > I'm wondering what is the need/purpose for DeepSeqIntegral and DeepSeqOrd? I don't actually know, they were previously NFDataIntegral and NFDataOrd respectively. Unless anyone can think of a reason to want these, I'll remove them. Cheers, Simon From marlowsd at gmail.com Wed Nov 18 04:17:31 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Nov 18 03:53:10 2009 Subject: ANNOUNCE: deepseq-1.0.0.0 In-Reply-To: References: <4B028245.1080201@gmail.com> Message-ID: <4B03BBAB.2090006@gmail.com> On 18/11/2009 03:48, Dean Herington wrote: > At 11:00 AM +0000 11/17/09, Simon Marlow wrote: >> I've just uploaded deepseq-1.0.0.0 to Hackage >> >> http://hackage.haskell.org/package/deepseq >> >> This provides a DeepSeq class with a deepseq method, equivalent to the >> existing NFData/rnf in the parallel package. I'll be using this in a >> newly revamped parallel package, which I hope to upload shortly. >> >> Cheers, >> Simon > > The documentation claim that "The default implementation of 'deepseq' is > simply 'seq'" is not exactly right, as `deepseq` and `seq` have > different signatures. Which raises the more interesting question: Why > did you choose a different signature? And, would a version of `seq` with > the same signature as `deepseq` be useful? So the main difference is that with the current formulation of deepseq, you need to explicitly force the result in order to use it, either with a pattern match, another seq, or a pseq. If we used (a -> b -> b) then the top-level forcing is "built-in". Let's look at an example instance; here (1) is the current deepseq, (2) is deepseq :: a -> b -> b instance (DeepSeq a, DeepSeq b) => DeepSeq (a,b) where -- (1) deepseq (a,b) = deepseq a `seq` deepseq b -- (2) deepseq (a,b) = deepseq a . deepseq b They're both fairly similar. Most instances follow this pattern, with seq being replaced by (.). You could argue that (a -> b -> b) is "doing more" than (a -> ()), because it has a kind of built-in continuation (Luke's point). I buy that, although (a -> ()) has a strange-looking unit type in the result and you have to use it in conjunction with seq. (1) generates slightly better code with GHC, because it compiles seq directly into a case expression, whereas (.) involves a thunk. If deepseq is inlined all the way down, then it would turn into the same thing either way. I don't feel terribly strongly, but I have a slight preference for the current version. Cheers, Simon From bulat.ziganshin at gmail.com Wed Nov 18 04:36:39 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Nov 18 04:12:19 2009 Subject: [Haskell-cafe] Re: ANNOUNCE: deepseq-1.0.0.0 In-Reply-To: <4B03BBAB.2090006@gmail.com> References: <4B028245.1080201@gmail.com> <4B03BBAB.2090006@gmail.com> Message-ID: <1174878203.20091118123639@gmail.com> Hello Simon, Wednesday, November 18, 2009, 12:17:31 PM, you wrote: > You could argue that (a -> b -> b) is "doing more" than (a -> ()), if i correctly understand, we have two versions: 1) easier to use 2) more efficient and one of them may be defined via another? how about providing both versions, with simpler name for simpler version? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jwlato at gmail.com Wed Nov 18 05:27:36 2009 From: jwlato at gmail.com (John Lato) Date: Wed Nov 18 05:03:01 2009 Subject: Could iteratee depend on mtl instead of transformers? Message-ID: <9979e72e0911180227m2e74a91bo38834559fde706f7@mail.gmail.com> > Date: Tue, 17 Nov 2009 11:59:56 +0100 (CET) > From: Henning Thielemann > > On Tue, 17 Nov 2009, Valery V. Vorotyntsev wrote: > >> Thus, the question is: are there any transformers-specific features >> iteratee package needs, or can it just go with mtl? > > The question is, whether Iteratee needs functions of MTL that transformers > does not provide? 'Transformers' is the more basic package, entirely > Haskell 98, thus should be prefered. It is however sad, that Transformers > cannot easily be used with GHCi in parallel with MTL installed. I was > always against that ... Renaming Control.Monad.Trans and > Control.Monad.Identity to something else would solve the conflict. I'm > also not happy, that you have to choose between monads-fd and monads-tf. I > think it would be better to be able to have both type class approaches. Iteratee does not need any MTL functions that transformers does not provide. It does the following: 1) implement instances of MonadTrans and MonadIO 2) uses lift and liftIO (polymorphically) There's no technical reason iteratee couldn't use mtl, and as Erik mentions, if you change the dependency it works just fine. For myself, I can be swayed by user demand, although I'd like to see the outcome of this discussion before committing to any changes. In all honesty, I never thought iteratee would generate enough interest for this to matter. It's not a particularly popular package. Cheers, John From valery.vv at gmail.com Wed Nov 18 05:42:19 2009 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Wed Nov 18 05:17:44 2009 Subject: iteratee (was: Could iteratee depend on mtl instead of transformers?) Message-ID: >> Valery V. Vorotyntsev wrote: >> >>> Thus, the question is: are there any transformers-specific features >>> iteratee package needs, or can it just go with mtl? > Henning Thielemann wrote: > >> The question is, whether Iteratee needs functions of MTL that transformers >> does not provide? 'Transformers' is the more basic package, entirely >> Haskell 98, thus should be prefered. It is however sad, that Transformers >> cannot easily be used with GHCi in parallel with MTL installed. I was >> always against that ... Renaming Control.Monad.Trans and >> Control.Monad.Identity to something else would solve the conflict. I'm >> also not happy, that you have to choose between monads-fd and monads-tf. I >> think it would be better to be able to have both type class approaches. John Lato wrote: > Iteratee does not need any MTL functions that transformers does not > provide. It does the following: > > 1) implement instances of MonadTrans and MonadIO > 2) uses lift and liftIO (polymorphically) > > There's no technical reason iteratee couldn't use mtl, and as Erik > mentions, if you change the dependency it works just fine. For > myself, I can be swayed by user demand, although I'd like to see the > outcome of this discussion before committing to any changes. I for one have no demand any more. I'm doing fine with the following lines in module: {-# LANGUAGE PackageImports #-} -- ... import "transformers" Control.Monad.Trans > In all honesty, I never thought iteratee would generate enough > interest for this to matter. It's not a particularly popular > package. I thought it was. :) http://comonad.com/reader/2009/iteratees-parsec-and-monoid/ http://therning.org/magnus/archives/735 http://stackoverflow.com/questions/1319705 http://www.johantibell.com/Left_fold_enumerators.pdf -- vvv From igloo at earth.li Wed Nov 18 07:12:44 2009 From: igloo at earth.li (Ian Lynagh) Date: Wed Nov 18 06:48:08 2009 Subject: ANNOUNCE: deepseq-1.0.0.0 In-Reply-To: <4B03BBAB.2090006@gmail.com> References: <4B028245.1080201@gmail.com> <4B03BBAB.2090006@gmail.com> Message-ID: <20091118121244.GA22164@matrix.chaos.earth.li> On Wed, Nov 18, 2009 at 09:17:31AM +0000, Simon Marlow wrote: > > I don't feel terribly strongly, but I have a slight preference for the > current version. I think something like deepseq :: a -> (a -> b) -> b would be best, so that it doesn't suffer from http://hackage.haskell.org/trac/ghc/ticket/2273 Thanks Ian From ekmett at gmail.com Wed Nov 18 08:04:11 2009 From: ekmett at gmail.com (Edward Kmett) Date: Wed Nov 18 07:39:38 2009 Subject: Could iteratee depend on mtl instead of transformers? In-Reply-To: References: <20091117124208.ffeb0a35.mle+hs@mega-nerd.com> <7fb8f82f0911162003x6ec712caw8c2c4f7a53dc0680@mail.gmail.com> <1258445961-sup-4987@peray> <29bf512f0911170456h7871a981tc49560b936640c@mail.gmail.com> <7fb8f82f0911170609r3bc24d82ic771e395ed414d72@mail.gmail.com> <20091117160430.GA14545@soi.city.ac.uk> <7fb8f82f0911171633l260390ddj221ef938474f3590@mail.gmail.com> Message-ID: <7fb8f82f0911180504j29b92977rb1e6e7b292fad2f0@mail.gmail.com> On Wed, Nov 18, 2009 at 2:44 AM, Ganesh Sittampalam wrote: > On Tue, 17 Nov 2009, Edward Kmett wrote: > > I guess the question is then, when should code start looking to changing >> their dependencies over to monads-tf and monads-fd? >> >> A cleanly demarked cut over would be useful to get us out of this limbo >> state that helps nobody. >> > > Are you suggesting that we declare a date or on which people should make > the switch? I think that might make some sense if we weren't already > accidentally part way through it, but given that we are, I'd say the best > option is to just do it asap once there is proper agreement. Substantively, I agree -- assuming that the issues that keep monads-tf and monads-fd from being loaded into the same program are fixed, so that library writers don't have to go through all of this again almost immediately. -Edward Kmett > > Ganesh > > _______________________________________________ > 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/20091118/c660af63/attachment.html From marlowsd at gmail.com Wed Nov 18 09:21:54 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Nov 18 08:57:38 2009 Subject: ANNOUNCE: parallel-2.0.0.0 Message-ID: <4B040302.4070202@gmail.com> I've just uploaded parallel-2.0.0.0 to Hackage. If you're using Strategies at all, I'd advise updating to this version of the parallel package. It's not completely API compatible, but if you're just using the supplied Strategies such as parList, the changes should be relatively minor. The Haddock docs include a full description of the changes, reproduced below. Haddock docs are also here, until Hackage catches up: http://www.haskell.org/~simonmar/parallel/index.html The Strategy-using programs I've tried so far go faster. Enjoy! Cheers, Simon --------------------------------------------------------------------- Version 1.x The original Strategies design is described in and the code was written by Phil Trinder, Hans-Wolfgang Loidl, Kevin Hammond et al. Version 2.x Later, during work on the shared-memory implementation of parallelism in GHC, we discovered that the original formulation of Strategies had some problems, in particular it lead to space leaks and difficulties expressing speculative parallelism. Details are in the paper \"Runtime Support for Multicore Haskell\" . This module has been rewritten in version 2. The main change is to the 'Strategy a' type synonym, which was previously @a -> Done@ and is now @a -> a@. This change helps to fix the space leak described in \"Runtime Support for Multicore Haskell\". The problem is that the runtime will currently retain the memory referenced by all sparks, until they are evaluated. Hence, we must arrange to evaluate all the sparks eventually, just in case they aren't evaluated in parallel, so that they don't cause a space leak. This is why we must return a \"new\" value after applying a 'Strategy', so that the application can evaluate each spark created by the 'Strategy'. The simple rule is this: you /must/ use the result of applying a 'Strategy' if the strategy creates parallel sparks, and you should probably discard the the original value. If you don't do this, currently it may result in a space leak. In the future (GHC 6.14), it will probably result in lost parallelism instead, as we plan to change GHC so that unreferenced sparks are discarded rather than retained (we can't make this change until most code is switched over to this new version of Strategies, because code using the old verison of Strategies would be broken by the change in policy). The other changes in version 2.x are: * Strategies can now be defined using a convenient Applicative type Eval. e.g. parList s = unEval $ traverse (Par . s) * 'parList' has been generalised to 'parTraverse', which works on any 'Traversable' type. * 'parList' and 'parBuffer' have versions specialised to 'rwhnf', and there are transformation rules that automatically translate e.g. @parList rwnhf@ into a call to the optimised version. * 'NFData' is deprecated; please use the @DeepSeq@ class in the @deepseq@ package instead. Note that since the 'Strategy' type changed, 'rnf' is no longer a 'Strategy': use 'rdeepseq' instead. From duncan.coutts at googlemail.com Wed Nov 18 09:39:10 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Wed Nov 18 09:14:46 2009 Subject: [Haskell-cafe] Re: ANNOUNCE: deepseq-1.0.0.0 In-Reply-To: <4B03BBAB.2090006@gmail.com> References: <4B028245.1080201@gmail.com> <4B03BBAB.2090006@gmail.com> Message-ID: <1258555150.4896.13804.camel@localhost> On Wed, 2009-11-18 at 09:17 +0000, Simon Marlow wrote: > So the main difference is that with the current formulation of deepseq, > you need to explicitly force the result in order to use it, either with > a pattern match, another seq, or a pseq. If we used (a -> b -> b) then > the top-level forcing is "built-in". > > Let's look at an example instance; here (1) is the current deepseq, (2) > is deepseq :: a -> b -> b > > instance (DeepSeq a, DeepSeq b) => DeepSeq (a,b) where > -- (1) deepseq (a,b) = deepseq a `seq` deepseq b > -- (2) deepseq (a,b) = deepseq a . deepseq b > > They're both fairly similar. Most instances follow this pattern, with > seq being replaced by (.). > > You could argue that (a -> b -> b) is "doing more" than (a -> ()), > because it has a kind of built-in continuation (Luke's point). I buy > that, although (a -> ()) has a strange-looking unit type in the result > and you have to use it in conjunction with seq. I think the most important thing is to make the public interface that people use most frequently simple and easy to remember. Thus I suggest the primary function people use should be deepseq :: DeepSeq a => a -> b -> b because then all that users have to remember is: "deepseq --- like seq but more so!" That's it. Users already know how to use seq, so now they know how to use deepseq too. > (1) generates slightly better code with GHC, because it compiles seq > directly into a case expression, whereas (.) involves a thunk. If > deepseq is inlined all the way down, then it would turn into the same > thing either way. > > I don't feel terribly strongly, but I have a slight preference for the > current version. If it so happens that it is more convenient or faster to make the class and instances use the (a -> ()) style then that is fine. We can give the class method a different name. Presumably people have to write Deepseq instances much less frequently than they use deepseq. Duncan From igloo at earth.li Wed Nov 18 09:47:58 2009 From: igloo at earth.li (Ian Lynagh) Date: Wed Nov 18 09:23:23 2009 Subject: Proposal (Trac ticket #3671): Add takeRec, genericTakeRec and spanRec to Data.List In-Reply-To: <1258470681.2704.16.camel@ewi1043> References: <1258465664.2704.6.camel@ewi1043> <20091117143517.GA443@matrix.chaos.earth.li> <1258470681.2704.16.camel@ewi1043> Message-ID: <20091118144758.GA20076@matrix.chaos.earth.li> On Tue, Nov 17, 2009 at 04:11:21PM +0100, Philip K.F. H?lzenspies wrote: > > Am I chalking you up as a +1? For splitAts, yes. My breaks has generally been such that breaks "123,456,,78" == ["123", "456", "", "78"] but the details probably depend on exactly what I've been using it for. I don't remember ever needing yours. I'd have thought that breaks :: (a -> Bool) -> [a] -> [([a], [a])] would make more sense, but personally I'd vote for not adding a breaks at all. Thanks Ian From duncan.coutts at googlemail.com Wed Nov 18 13:04:24 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Wed Nov 18 12:39:53 2009 Subject: Could iteratee depend on mtl instead of transformers? In-Reply-To: <20091118005719.GA26862@soi.city.ac.uk> References: <20091117124208.ffeb0a35.mle+hs@mega-nerd.com> <7fb8f82f0911162003x6ec712caw8c2c4f7a53dc0680@mail.gmail.com> <1258445961-sup-4987@peray> <29bf512f0911170456h7871a981tc49560b936640c@mail.gmail.com> <7fb8f82f0911170609r3bc24d82ic771e395ed414d72@mail.gmail.com> <20091117160430.GA14545@soi.city.ac.uk> <7fb8f82f0911171633l260390ddj221ef938474f3590@mail.gmail.com> <20091118005719.GA26862@soi.city.ac.uk> Message-ID: <1258567464.4896.14664.camel@localhost> On Wed, 2009-11-18 at 00:57 +0000, Ross Paterson wrote: > According to Ganesh's survey, 17 packages (and their dependents) on > hackage would be broken by turning mtl into a compatibility layer over > transformers+monads-fd. They would need to be updated, but need not > switch to monads-tf or monads-fd. Or they could avoid breakage by > adding a dependency mtl < 2. Individual packages could switch to > the new packages at their leisure. Ross, if the plan is to have the new combined package be mtl-2.x then you might as well go ahead and modify the preferred-versions[1] file to add: mtl < 2 Then cabal-install will then use the old mtl for all the old packages that do not use an upper bound. We should also add mtl to the list packages to check in Distribution/PackageDescription/Check.hs. At the moment it's hard-coded to be a list of 1 (base), so that'd need doing too. This would eventually be replaced by a generic way of opting into the regime. Or, if you all think the amount of breakage is not that great, and it'd be simpler just to fix the packages affected, then do nothing :-) If you are modifying the preferred-versions file, would you mind sticking in: cabal-install < 0.8 because I'm about to release both cabal-install-0.6.4 and 0.8.0, but I don't want everyone getting prompted to update to 0.8 immediately (cabal tells you when newer versions of itself are available). Duncan [1] http://hackage.haskell.org/packages/archive/preferred-versions From ekmett at gmail.com Wed Nov 18 17:09:09 2009 From: ekmett at gmail.com (Edward Kmett) Date: Wed Nov 18 16:44:40 2009 Subject: [Haskell-cafe] ANNOUNCE: parallel-2.0.0.0 In-Reply-To: <4B040302.4070202@gmail.com> References: <4B040302.4070202@gmail.com> Message-ID: <7fb8f82f0911181409r1495483s5be5ba39e189643b@mail.gmail.com> I love the new Eval Applicative! Out of idle curiosity, can parListN be generalized to parTraverseN similar to how parList was generalized to parTraverse? Similarly, parListChunk? -Edward Kmett On Wed, Nov 18, 2009 at 9:21 AM, Simon Marlow wrote: > I've just uploaded parallel-2.0.0.0 to Hackage. If you're using Strategies > at all, I'd advise updating to this version of the parallel package. It's > not completely API compatible, but if you're just using the supplied > Strategies such as parList, the changes should be relatively minor. > > The Haddock docs include a full description of the changes, reproduced > below. Haddock docs are also here, until Hackage catches up: > > http://www.haskell.org/~simonmar/parallel/index.html > > The Strategy-using programs I've tried so far go faster. Enjoy! > > Cheers, > Simon > > --------------------------------------------------------------------- > > Version 1.x > > The original Strategies design is described in > > > > > and the code was written by > Phil Trinder, Hans-Wolfgang Loidl, Kevin Hammond et al. > > Version 2.x > > Later, during work on the shared-memory implementation of > parallelism in GHC, we discovered that the original formulation of > Strategies had some problems, in particular it lead to space leaks > and difficulties expressing speculative parallelism. Details are in > the paper \"Runtime Support for Multicore Haskell\" < > http://www.haskell.org/~simonmar/papers/multicore-ghc.pdf > >. > > This module has been rewritten in version 2. The main change is to > the 'Strategy a' type synonym, which was previously @a -> Done@ and > is now @a -> a@. This change helps to fix the space leak described > in \"Runtime Support for Multicore Haskell\". The problem is that > the runtime will currently retain the memory referenced by all > sparks, until they are evaluated. Hence, we must arrange to > evaluate all the sparks eventually, just in case they aren't > evaluated in parallel, so that they don't cause a space leak. This > is why we must return a \"new\" value after applying a 'Strategy', > so that the application can evaluate each spark created by the > 'Strategy'. > > The simple rule is this: you /must/ use the result of applying > a 'Strategy' if the strategy creates parallel sparks, and you > should probably discard the the original value. If you don't > do this, currently it may result in a space leak. In the > future (GHC 6.14), it will probably result in lost parallelism > instead, as we plan to change GHC so that unreferenced sparks > are discarded rather than retained (we can't make this change > until most code is switched over to this new version of > Strategies, because code using the old verison of Strategies > would be broken by the change in policy). > > The other changes in version 2.x are: > > * Strategies can now be defined using a convenient Applicative > type Eval. e.g. parList s = unEval $ traverse (Par . s) > > * 'parList' has been generalised to 'parTraverse', which works on > any 'Traversable' type. > > * 'parList' and 'parBuffer' have versions specialised to 'rwhnf', > and there are transformation rules that automatically translate > e.g. @parList rwnhf@ into a call to the optimised version. > > * 'NFData' is deprecated; please use the @DeepSeq@ class in the @deepseq@ > package instead. Note that since the 'Strategy' type changed, 'rnf' > is no longer a 'Strategy': use 'rdeepseq' instead. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20091118/0a85a32a/attachment.html From gale at sefer.org Wed Nov 18 17:42:17 2009 From: gale at sefer.org (Yitzchak Gale) Date: Wed Nov 18 17:18:01 2009 Subject: Proposal (Trac ticket #3671): Add takeRec, genericTakeRec and spanRec to Data.List In-Reply-To: <20091117143517.GA443@matrix.chaos.earth.li> References: <1258465664.2704.6.camel@ewi1043> <20091117143517.GA443@matrix.chaos.earth.li> Message-ID: <2608b8a80911181442k1525eb1r1fc5b2ef32d7ecc5@mail.gmail.com> Philip K.F. H?lzenspies wrote: >> After defining these for the umpeenth time, I would like to add the >> functions takeRec, genericTakeRec and spanRec to Data.List, as per >> http://hackage.haskell.org/trac/ghc/ticket/3671 Ian Lynagh wrote: > I have also defined your "takeRec" a number of times in the past, but I > have called it something like "splitAts". I've been using it for years, under the name "groupsOf" - which is also consistent with Data.List naming conventions, and a bit less confusing than "splitAts" in my opinion. Another reason I don't use splitAts is that I don't use splitAt in its definition anymore; I've come to prefer groupsOf n = takeWhile (not . null) . map (take n) . iterate (drop n) In fact, I use this function so much that I put it in my dot-ghci so it will always be at my fingertips. I am very much in favor of adding it to Data.List. Regards, Yitz From ross at soi.city.ac.uk Wed Nov 18 19:28:38 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Nov 18 19:03:32 2009 Subject: Could iteratee depend on mtl instead of transformers? In-Reply-To: <1258567464.4896.14664.camel@localhost> References: <20091117124208.ffeb0a35.mle+hs@mega-nerd.com> <7fb8f82f0911162003x6ec712caw8c2c4f7a53dc0680@mail.gmail.com> <1258445961-sup-4987@peray> <29bf512f0911170456h7871a981tc49560b936640c@mail.gmail.com> <7fb8f82f0911170609r3bc24d82ic771e395ed414d72@mail.gmail.com> <20091117160430.GA14545@soi.city.ac.uk> <7fb8f82f0911171633l260390ddj221ef938474f3590@mail.gmail.com> <20091118005719.GA26862@soi.city.ac.uk> <1258567464.4896.14664.camel@localhost> Message-ID: <20091119002838.GA25218@soi.city.ac.uk> On Wed, Nov 18, 2009 at 06:04:24PM +0000, Duncan Coutts wrote: > Ross, if the plan is to have the new combined package be mtl-2.x then > you might as well go ahead and modify the preferred-versions file to > add: > > mtl < 2 > > Then cabal-install will then use the old mtl for all the old packages > that do not use an upper bound. > > We should also add mtl to the list packages to check in > Distribution/PackageDescription/Check.hs. At the moment it's hard-coded > to be a list of 1 (base), so that'd need doing too. This would > eventually be replaced by a generic way of opting into the regime. > > Or, if you all think the amount of breakage is not that great, and it'd > be simpler just to fix the packages affected, then do nothing :-) I've just realized that it's not going to be as painless as we thought, and I'm not sure this is something preferred-versions can help with. (But I still think the transition is worth doing.) My original plan was to refactor mtl as transformers + monads-fd, so that together they'd offer a bunch of modules that were near-compatible with the modules of the same name in mtl. In only a tiny minority of cases would it be necessary to change code, but everyone would have to replace their dependencies on mtl with dependencies on transformers and monads-fd (though the latter wouldn't always be needed). Then Ganesh whipped up an mtl compatibility package, that re-exported modules from the two packages. Almost all the packages in hackage would compile unchanged if this package was mtl-2.0. But there's a problem: even if we rename the modules in monads-fd, we still have two modules in transformers that have the same names as modules in mtl, namely Control.Monad.Identity and Control.Monad.Trans. Renaming isn't an option: at least the first of those is the Right Name for the module concerned. People who build with cabal are fine: only the dependent packages are exposed, and all packages use the same type constructors, so the interfaces are compatible. But people who build with ghci or ghc --make will get the error message at the top of this thread: Could not find module `Control.Monad.Identity': it was found in multiple packages: mtl-2.0 transformers-0.1.4.0 So I think we're back at the original plan: a big bang replacement of dependencies on mtl with dependencies on transformers and monads-fd. (Unless we introduce virtual packages.) After that we could rename the FD-using modules slowly using the usual deprecation procedure. But we should rename the modules in monads-tf now -- all that needs is for someone to suggest good names. > If you are modifying the preferred-versions file, would you mind > sticking in: > > cabal-install < 0.8 done From lemming at henning-thielemann.de Wed Nov 18 19:48:41 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Nov 18 19:21:44 2009 Subject: Could iteratee depend on mtl instead of transformers? In-Reply-To: <9979e72e0911180227m2e74a91bo38834559fde706f7@mail.gmail.com> References: <9979e72e0911180227m2e74a91bo38834559fde706f7@mail.gmail.com> Message-ID: <4B0495E9.5010907@henning-thielemann.de> John Lato schrieb: > There's no technical reason iteratee couldn't use mtl, and as Erik > mentions, if you change the dependency it works just fine. For > myself, I can be swayed by user demand, although I'd like to see the > outcome of this discussion before committing to any changes. > > In all honesty, I never thought iteratee would generate enough > interest for this to matter. It's not a particularly popular package. Please leave iteratee importing transformers! From lemming at henning-thielemann.de Wed Nov 18 20:14:13 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Nov 18 19:49:37 2009 Subject: [Haskell-cafe] ANNOUNCE: parallel-2.0.0.0 In-Reply-To: <4B040302.4070202@gmail.com> References: <4B040302.4070202@gmail.com> Message-ID: On Wed, 18 Nov 2009, Simon Marlow wrote: > I've just uploaded parallel-2.0.0.0 to Hackage. If you're using Strategies > at all, I'd advise updating to this version of the parallel package. It's > not completely API compatible, but if you're just using the supplied > Strategies such as parList, the changes should be relatively minor. Are there plans to turn Strategy and Done into individual types rather than type synonyms? Or is there any benefit from using type synonyms? From malcolm.wallace at cs.york.ac.uk Wed Nov 18 20:15:17 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Nov 18 19:52:05 2009 Subject: Proposal (Trac ticket #3671): Add takeRec, genericTakeRec and spanRec to Data.List In-Reply-To: <2608b8a80911181442k1525eb1r1fc5b2ef32d7ecc5@mail.gmail.com> References: <1258465664.2704.6.camel@ewi1043> <20091117143517.GA443@matrix.chaos.earth.li> <2608b8a80911181442k1525eb1r1fc5b2ef32d7ecc5@mail.gmail.com> Message-ID: > groupsOf n = takeWhile (not . null) . map (take n) . iterate (drop n) +1 for the name. Nice combinator-based definition too. (How does its performance compare to a directly recursive defn??) Regards, Malcolm From bulat.ziganshin at gmail.com Wed Nov 18 22:28:49 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Nov 18 22:04:21 2009 Subject: Proposal (Trac ticket #3671): Add takeRec, genericTakeRec and spanRec to Data.List In-Reply-To: References: <1258465664.2704.6.camel@ewi1043> <20091117143517.GA443@matrix.chaos.earth.li> <2608b8a80911181442k1525eb1r1fc5b2ef32d7ecc5@mail.gmail.com> Message-ID: <884298590.20091119062849@gmail.com> Hello Malcolm, Thursday, November 19, 2009, 4:15:17 AM, you wrote: >> groupsOf n = takeWhile (not . null) . map (take n) . iterate (drop n) > +1 for the name. Nice combinator-based definition too. (How does its > performance compare to a directly recursive defn??) take+drop combination should be slower than splitAt -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From malcolm.wallace at cs.york.ac.uk Wed Nov 18 23:14:45 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Nov 18 22:52:06 2009 Subject: Proposal (Trac ticket #3671): Add takeRec, genericTakeRec and spanRec to Data.List In-Reply-To: <884298590.20091119062849@gmail.com> References: <1258465664.2704.6.camel@ewi1043> <20091117143517.GA443@matrix.chaos.earth.li> <2608b8a80911181442k1525eb1r1fc5b2ef32d7ecc5@mail.gmail.com> <884298590.20091119062849@gmail.com> Message-ID: > take+drop combination should be slower than splitAt I suppose the only convincing argument is empirical. Using the following simple and unscientific benchmark, it turns out that take +drop is ~ 2x faster than splitAt. Maybe list fusion or something is kicking in. main = do print (length (splitAts 15 bigList)) main' = do print (length (groupsOf 15 bigList)) bigList = replicate 15000000 () groupsOf n = takeWhile (not . null) . map (take n) . iterate (drop n) splitAts n [] = [] splitAts n xs = let (a,b) = splitAt n xs in a: splitAts n b time ./groupsOf 1000000 real 0m0.234s user 0m0.225s sys 0m0.006s time ./splitAts 1000000 real 0m0.557s user 0m0.542s sys 0m0.012s Regards, Malcolm From marlowsd at gmail.com Thu Nov 19 03:51:15 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Nov 19 03:26:41 2009 Subject: [Haskell-cafe] ANNOUNCE: parallel-2.0.0.0 In-Reply-To: References: <4B040302.4070202@gmail.com> Message-ID: <4B050703.2090504@gmail.com> On 19/11/2009 01:14, Henning Thielemann wrote: > > On Wed, 18 Nov 2009, Simon Marlow wrote: > >> I've just uploaded parallel-2.0.0.0 to Hackage. If you're using >> Strategies at all, I'd advise updating to this version of the parallel >> package. It's not completely API compatible, but if you're just using >> the supplied Strategies such as parList, the changes should be >> relatively minor. > > Are there plans to turn Strategy and Done into individual types rather > than type synonyms? Or is there any benefit from using type synonyms? Done is gone, so to speak. Let me turn the question round: what benefits do you see from turning Strategy into a newtype? Cheers, Simon From josef.svenningsson at gmail.com Thu Nov 19 05:11:08 2009 From: josef.svenningsson at gmail.com (Josef Svenningsson) Date: Thu Nov 19 04:46:32 2009 Subject: Proposal (Trac ticket #3671): Add takeRec, genericTakeRec and spanRec to Data.List In-Reply-To: <20091118144758.GA20076@matrix.chaos.earth.li> References: <1258465664.2704.6.camel@ewi1043> <20091117143517.GA443@matrix.chaos.earth.li> <1258470681.2704.16.camel@ewi1043> <20091118144758.GA20076@matrix.chaos.earth.li> Message-ID: <8dde104f0911190211u29f0f0bai5dbcddce4f4e11@mail.gmail.com> On Wed, Nov 18, 2009 at 3:47 PM, Ian Lynagh wrote: > On Tue, Nov 17, 2009 at 04:11:21PM +0100, Philip K.F. H?lzenspies wrote: >> >> Am I chalking you up as a +1? > > For splitAts, yes. > > My breaks has generally been such that > ? ?breaks "123,456,,78" == ["123", "456", "", "78"] > but the details probably depend on exactly what I've been using it for. > I've been using this kind of breaks as well in the past. Is there a usecase for a more general version? Apart from that I'm positive towards the groupsOf function. Josef From p.k.f.holzenspies at utwente.nl Thu Nov 19 05:47:31 2009 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?ISO-8859-1?Q?H=F6lzenspies?=) Date: Thu Nov 19 05:22:55 2009 Subject: Proposal (Trac ticket #3671): Add takeRec, genericTakeRec and spanRec to Data.List In-Reply-To: References: <1258465664.2704.6.camel@ewi1043> <20091117143517.GA443@matrix.chaos.earth.li> <2608b8a80911181442k1525eb1r1fc5b2ef32d7ecc5@mail.gmail.com> <884298590.20091119062849@gmail.com> Message-ID: <1258627651.7681.62.camel@ewi1043> Dear Malcolm, Ian, et al. On Thu, 2009-11-19 at 04:14 +0000, Malcolm Wallace wrote: > I suppose the only convincing argument is empirical. Hear, hear! Although... the empirical argument changes with the versions of the compiler. Anyone up for an evaluation of alternative implementations of all functions in base? :p > Using the > following simple and unscientific benchmark, it turns out that take > +drop is ~ 2x faster than splitAt. Maybe list fusion or something is > kicking in. Is it possible that the tuple wrapping and unwrapping in the splitAt-implementation hurts optimization? On Wed, 2009-11-18 at 14:47 +0000, Ian Lynagh wrote: > My breaks has generally been such that > breaks "123,456,,78" == ["123", "456", "", "78"] > but the details probably depend on exactly what I've been using it for. > > I don't remember ever needing yours. I'd have thought that > breaks :: (a -> Bool) -> [a] -> [([a], [a])] > would make more sense, but personally I'd vote for not adding a breaks > at all. The more I looked at the spans/breaks, the more I figured that didn't quite cover the majority of cases for which I hack in extra functionality. I think I have it down to the bare bones of what I was missing; there's no function in Data.List to segment a list based on sequence properties. In other words, there is no way to extract runs (or clumps, if you prefer). An alternative suggestion, thus: runs :: (a -> a -> Bool) -> [a] -> [[a]] runs p xs = ... which produces a list of runs, i.e. the first result is that prefix of xs, such that for all consecutive elements e_i, e_{i+1}, the property holds, i.e. p e_i e_{i+1} -->> True. Although not exactly equivalent, spans' can be implemented as: spans' p = runs (\x y -> p x == p y) the difference being the first span: > spans odd [2,3,4,5,7,9,8,0,3,5,9] [[],[2],[3],[4],[5,7,9],[8,0],[3,5,9]] > spans' odd [2,3,4,5,7,9,8,0,3,5,9] [[2],[3],[4],[5,7,9],[8,0],[3,5,9]] This difference is of no consequence to the types of programs I used spans in. This new implementation makes spans so simple that inclusion in Data.List is no longer necessary. So my new proposal would be to include groupsOf and runs. Now for the empirical stuff. I have two implementations: runs :: (a -> a -> Bool) -> [a] -> [[a]] runs _ [ ] = [] runs _ [x] = [[x]] runs p (x:xs) = r : runs p xs' where (r,xs') = run x xs cons' x (xs,y) = (x:xs,y) run y [] = ([y],[]) run y l@(x:xs) | p y x = cons' y $ run x xs | otherwise = ([y],l) runsAlt :: (a -> a -> Bool) -> [a] -> [[a]] runsAlt _ [] = [[]] runsAlt _ xs@[x] = [xs] runsAlt p (x:xs@(y:_)) | p x y = (x : head xs') : tail xs' | otherwise = [x]:xs' where xs' = runsAlt p xs (I welcome suggestions for improvements.) Used in the program: bigList = concat $ replicate 10000000 [5,6,9,1,3,4,2] main = print (length (runs (>) bigList)) compiled without and with -O2: runs : 5.40s user 0.03s system 99% cpu 5.438 total runsOpt : 4.40s user 0.03s system 99% cpu 4.440 total runsAlt : 4.89s user 0.04s system 99% cpu 4.934 total runsAltOpt : 4.14s user 0.03s system 99% cpu 4.207 total We have a winner ;) Regards, Philip From marlowsd at gmail.com Thu Nov 19 06:24:03 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Nov 19 05:59:37 2009 Subject: [Haskell-cafe] Re: ANNOUNCE: deepseq-1.0.0.0 In-Reply-To: <4EAD957A-8BDC-4BFD-85D9-39B74D638556@cs.york.ac.uk> References: <4B028245.1080201@gmail.com> <4EAD957A-8BDC-4BFD-85D9-39B74D638556@cs.york.ac.uk> Message-ID: <4B052AD3.4040801@gmail.com> On 18/11/2009 04:05, Malcolm Wallace wrote: >> The documentation claim that "The default implementation of 'deepseq' >> is simply 'seq'" is not exactly right, as `deepseq` and `seq` have >> different signatures. > > Yes indeed. In order to use deepseq, it looks like I also need some way > to force the () return value, e.g. > > let res = deepseq (my big computation) > in res `seq` use res > > or > > let res = deepseq (my big computation) > in case res of () -> use res or let !res = deepseq (my big computation) in use res Cheers, Simon From gale at sefer.org Thu Nov 19 06:28:12 2009 From: gale at sefer.org (Yitzchak Gale) Date: Thu Nov 19 06:05:21 2009 Subject: Proposal (Trac ticket #3671): Add takeRec, genericTakeRec and spanRec to Data.List In-Reply-To: <1258627651.7681.62.camel@ewi1043> References: <1258465664.2704.6.camel@ewi1043> <20091117143517.GA443@matrix.chaos.earth.li> <2608b8a80911181442k1525eb1r1fc5b2ef32d7ecc5@mail.gmail.com> <884298590.20091119062849@gmail.com> <1258627651.7681.62.camel@ewi1043> Message-ID: <2608b8a80911190328g3a43ad2eoedbdded5bf1f349@mail.gmail.com> Philip K.F. wrote: > runs :: (a -> a -> Bool) -> [a] -> [[a]] > runs p xs = ... > > which produces a list of runs, i.e. the first result is that prefix of > xs, such that for all consecutive elements e_i, e_{i+1}, the property > holds, i.e. p e_i e_{i+1} -->> True. We already have something like that: groupBy :: (a -> a -> Bool) -> [a] -> [[a]] In fact, instead of spans and breaks, why not just use: runs :: (a -> Bool) -> [a] -> [[a]] runs = groupBy . on (==) Then we have: breaks p = runs p . dropWhile p spans p = runs p . dropWhile (not . p) Regards, Yitz From marlowsd at gmail.com Thu Nov 19 06:36:12 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Nov 19 06:11:41 2009 Subject: ANNOUNCE: deepseq-1.0.0.0 In-Reply-To: <20091118121244.GA22164@matrix.chaos.earth.li> References: <4B028245.1080201@gmail.com> <4B03BBAB.2090006@gmail.com> <20091118121244.GA22164@matrix.chaos.earth.li> Message-ID: <4B052DAC.9060405@gmail.com> On 18/11/2009 12:12, Ian Lynagh wrote: > On Wed, Nov 18, 2009 at 09:17:31AM +0000, Simon Marlow wrote: >> >> I don't feel terribly strongly, but I have a slight preference for the >> current version. > > I think something like > > deepseq :: a -> (a -> b) -> b > > would be best, so that it doesn't suffer from > > http://hackage.haskell.org/trac/ghc/ticket/2273 I don't mind supplying that too, with a comment to explain why it's there. Although we could recommend that people use the bang-pattern idiom instead, where that's available. The main question still to be resolved is what names to use. I agree with Duncan's point that deepseq should have the same type as seq, to reduce confusion. So then what shall we call the a -> () version? One possibility is to go back to calling it rnf. Any other ideas? Cheers, Simon From gale at sefer.org Thu Nov 19 06:45:15 2009 From: gale at sefer.org (Yitzchak Gale) Date: Thu Nov 19 06:20:58 2009 Subject: ANNOUNCE: deepseq-1.0.0.0 In-Reply-To: <4B052DAC.9060405@gmail.com> References: <4B028245.1080201@gmail.com> <4B03BBAB.2090006@gmail.com> <20091118121244.GA22164@matrix.chaos.earth.li> <4B052DAC.9060405@gmail.com> Message-ID: <2608b8a80911190345u4887e0b7r9d23d98186621a46@mail.gmail.com> Simon Marlow wrote: > So then what shall we call the a -> () version? > One possibility is to go back to calling it rnf. In light of apfelmus' comment, I vote for rnf. And in that case, how about the analogous alternative for seq itself: hnf :: a -> () Thanks, Yitz From igloo at earth.li Thu Nov 19 06:46:42 2009 From: igloo at earth.li (Ian Lynagh) Date: Thu Nov 19 06:22:04 2009 Subject: Proposal (Trac ticket #3671): Add takeRec, genericTakeRec and spanRec to Data.List In-Reply-To: <8dde104f0911190211u29f0f0bai5dbcddce4f4e11@mail.gmail.com> References: <1258465664.2704.6.camel@ewi1043> <20091117143517.GA443@matrix.chaos.earth.li> <1258470681.2704.16.camel@ewi1043> <20091118144758.GA20076@matrix.chaos.earth.li> <8dde104f0911190211u29f0f0bai5dbcddce4f4e11@mail.gmail.com> Message-ID: <20091119114642.GA27086@matrix.chaos.earth.li> On Thu, Nov 19, 2009 at 11:11:08AM +0100, Josef Svenningsson wrote: > On Wed, Nov 18, 2009 at 3:47 PM, Ian Lynagh wrote: > > On Tue, Nov 17, 2009 at 04:11:21PM +0100, Philip K.F. H?lzenspies wrote: > >> > >> Am I chalking you up as a +1? > > > > For splitAts, yes. > > > > My breaks has generally been such that > > ? ?breaks "123,456,,78" == ["123", "456", "", "78"] > > but the details probably depend on exactly what I've been using it for. > > > I've been using this kind of breaks as well in the past. Is there a > usecase for a more general version? Ooops, I actually meant breaks (',' ==) "123,456,,78" == ["123", "456", "", "78"] but personally I don't think this should be standardised. Thanks Ian From ganesh.sittampalam at credit-suisse.com Thu Nov 19 06:52:48 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Thu Nov 19 06:28:22 2009 Subject: ANNOUNCE: deepseq-1.0.0.0 In-Reply-To: <2608b8a80911190345u4887e0b7r9d23d98186621a46@mail.gmail.com> References: <4B028245.1080201@gmail.com> <4B03BBAB.2090006@gmail.com><20091118121244.GA22164@matrix.chaos.earth.li> <4B052DAC.9060405@gmail.com> <2608b8a80911190345u4887e0b7r9d23d98186621a46@mail.gmail.com> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B03B9FCD2@ELON17P32001A.csfb.cs-group.com> Yitzchak Gale wrote: > Simon Marlow wrote: >> So then what shall we call the a -> () version? >> One possibility is to go back to calling it rnf. > > In light of apfelmus' comment, I vote for rnf. > > And in that case, how about the analogous alternative for seq itself: > > hnf :: a -> () I think it would be whnf since it doesn't evaluate under lambdas. I also vote for rnf, because we should have a good reason for changing names of things. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From bulat.ziganshin at gmail.com Thu Nov 19 06:52:57 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Nov 19 06:28:32 2009 Subject: ANNOUNCE: deepseq-1.0.0.0 In-Reply-To: <4B052DAC.9060405@gmail.com> References: <4B028245.1080201@gmail.com> <4B03BBAB.2090006@gmail.com> <20091118121244.GA22164@matrix.chaos.earth.li> <4B052DAC.9060405@gmail.com> Message-ID: <1448533309.20091119145257@gmail.com> Hello Simon, Thursday, November 19, 2009, 2:36:12 PM, you wrote: > The main question still to be resolved is what names to use. I agree > with Duncan's point that deepseq should have the same type as seq, to > reduce confusion. So then what shall we call the a -> () version? not that i vote for it, just idea: deepseq_ like monadic *_ functions -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From lemming at henning-thielemann.de Thu Nov 19 07:00:38 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Nov 19 06:33:56 2009 Subject: [Haskell-cafe] ANNOUNCE: parallel-2.0.0.0 In-Reply-To: <4B050703.2090504@gmail.com> References: <4B040302.4070202@gmail.com> <4B050703.2090504@gmail.com> Message-ID: <4B053366.6000301@henning-thielemann.de> Simon Marlow schrieb: > On 19/11/2009 01:14, Henning Thielemann wrote: >> >> Are there plans to turn Strategy and Done into individual types rather >> than type synonyms? Or is there any benefit from using type synonyms? > > Done is gone, so to speak. > > Let me turn the question round: what benefits do you see from turning > Strategy into a newtype? Usually you will not apply a strategy as function to a value. A newtype would prevent you from doing so accidentally. But since the definition of Strategy has changed, my objection might no longer be valid ... From gale at sefer.org Thu Nov 19 07:07:10 2009 From: gale at sefer.org (Yitzchak Gale) Date: Thu Nov 19 06:44:10 2009 Subject: Proposal (Trac ticket #3671): Add takeRec, genericTakeRec and spanRec to Data.List In-Reply-To: <20091119114642.GA27086@matrix.chaos.earth.li> References: <1258465664.2704.6.camel@ewi1043> <20091117143517.GA443@matrix.chaos.earth.li> <1258470681.2704.16.camel@ewi1043> <20091118144758.GA20076@matrix.chaos.earth.li> <8dde104f0911190211u29f0f0bai5dbcddce4f4e11@mail.gmail.com> <20091119114642.GA27086@matrix.chaos.earth.li> Message-ID: <2608b8a80911190407s5b36d497gcdabd217ebe2dfdd@mail.gmail.com> Ian Lynagh wrote: > ? ?breaks (',' ==) "123,456,,78" == ["123", "456", "", "78"] Yes, that is very useful, and we get the other semantics from "runs". So as of now, I am leaning towards: runs = groupBy . on (==) spans p = filter (p . head) . runs p breaks p = filter (not . p . head) . runs p > but personally I don't think this should be standardised. All of these functions are very simple combinations of existing ones. On the other hand, it took us until now to realize that, so I'm not sure. In any case, I definitely would like to see groupsOf (or a rose by any other name) in the library. Thanks, Yitz From gale at sefer.org Thu Nov 19 07:15:07 2009 From: gale at sefer.org (Yitzchak Gale) Date: Thu Nov 19 06:50:48 2009 Subject: Proposal (Trac ticket #3671): Add takeRec, genericTakeRec and spanRec to Data.List In-Reply-To: <2608b8a80911190407s5b36d497gcdabd217ebe2dfdd@mail.gmail.com> References: <1258465664.2704.6.camel@ewi1043> <20091117143517.GA443@matrix.chaos.earth.li> <1258470681.2704.16.camel@ewi1043> <20091118144758.GA20076@matrix.chaos.earth.li> <8dde104f0911190211u29f0f0bai5dbcddce4f4e11@mail.gmail.com> <20091119114642.GA27086@matrix.chaos.earth.li> <2608b8a80911190407s5b36d497gcdabd217ebe2dfdd@mail.gmail.com> Message-ID: <2608b8a80911190415h59b7f2bara5ec9a5427f3f247@mail.gmail.com> Ian Lynagh wrote: >> ? ?breaks (',' ==) "123,456,,78" == ["123", "456", "", "78"] I wrote: > runs = groupBy . on (==) > breaks p = filter (not . p . head) . runs p Except that has slightly different semantics than Ian's: breaks (',' ==) "123,456,,78" == ["123","456","78"] -Yitz From marlowsd at gmail.com Thu Nov 19 07:17:43 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Nov 19 06:53:17 2009 Subject: ANNOUNCE: deepseq-1.0.0.0 In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B03B9FCD2@ELON17P32001A.csfb.cs-group.com> References: <4B028245.1080201@gmail.com> <4B03BBAB.2090006@gmail.com><20091118121244.GA22164@matrix.chaos.earth.li> <4B052DAC.9060405@gmail.com> <2608b8a80911190345u4887e0b7r9d23d98186621a46@mail.gmail.com> <16442B752A06A74AB4D9F9A5FF076E4B03B9FCD2@ELON17P32001A.csfb.cs-group.com> Message-ID: <4B053767.8060201@gmail.com> On 19/11/2009 11:52, Sittampalam, Ganesh wrote: > Yitzchak Gale wrote: >> Simon Marlow wrote: >>> So then what shall we call the a -> () version? >>> One possibility is to go back to calling it rnf. >> >> In light of apfelmus' comment, I vote for rnf. >> >> And in that case, how about the analogous alternative for seq itself: >> >> hnf :: a -> () > > I think it would be whnf since it doesn't evaluate under lambdas. > > I also vote for rnf, because we should have a good reason for changing > names of things. Various people would prefer rnf. Ok, unless there are any further objections, I'll change the names back to class NFData a where rnf :: a -> () and also add deepseq :: a -> b -> b but I'll leave the module name as Control.DeepSeq. Cheers, Simon From gale at sefer.org Thu Nov 19 07:24:23 2009 From: gale at sefer.org (Yitzchak Gale) Date: Thu Nov 19 07:00:06 2009 Subject: Proposal (Trac ticket #3671): Add takeRec, genericTakeRec and spanRec to Data.List In-Reply-To: <2608b8a80911190415h59b7f2bara5ec9a5427f3f247@mail.gmail.com> References: <1258465664.2704.6.camel@ewi1043> <20091117143517.GA443@matrix.chaos.earth.li> <1258470681.2704.16.camel@ewi1043> <20091118144758.GA20076@matrix.chaos.earth.li> <8dde104f0911190211u29f0f0bai5dbcddce4f4e11@mail.gmail.com> <20091119114642.GA27086@matrix.chaos.earth.li> <2608b8a80911190407s5b36d497gcdabd217ebe2dfdd@mail.gmail.com> <2608b8a80911190415h59b7f2bara5ec9a5427f3f247@mail.gmail.com> Message-ID: <2608b8a80911190424v3969b4aenba9326c3a8d4dfed@mail.gmail.com> Ian Lynagh wrote: >>> ? ?breaks (',' ==) "123,456,,78" == ["123", "456", "", "78"] I wrote: >> runs = groupBy . on (==) >> breaks p = filter (not . p . head) . runs p > Except that has slightly different semantics than Ian's: > breaks (',' ==) "123,456,,78" == ["123","456","78"] A combinator approach to Ian's semantics: spans p = map (takeWhile p) . takeWhile (not . null) . iterate (drop 1 . dropWhile p) breaks p = spans $ not . p Here you have to put the "not null" step in the middle. I wonder if that interferes with the fusion. -Yitz From p.k.f.holzenspies at utwente.nl Thu Nov 19 09:02:12 2009 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?ISO-8859-1?Q?H=F6lzenspies?=) Date: Thu Nov 19 08:37:29 2009 Subject: Proposal (Trac ticket #3671): Add takeRec, genericTakeRec and spanRec to Data.List In-Reply-To: <2608b8a80911190328g3a43ad2eoedbdded5bf1f349@mail.gmail.com> References: <1258465664.2704.6.camel@ewi1043> <20091117143517.GA443@matrix.chaos.earth.li> <2608b8a80911181442k1525eb1r1fc5b2ef32d7ecc5@mail.gmail.com> <884298590.20091119062849@gmail.com> <1258627651.7681.62.camel@ewi1043> <2608b8a80911190328g3a43ad2eoedbdded5bf1f349@mail.gmail.com> Message-ID: <1258639332.7681.75.camel@ewi1043> On Thu, 2009-11-19 at 13:28 +0200, Yitzchak Gale wrote: > Philip K.F. wrote: > > runs :: (a -> a -> Bool) -> [a] -> [[a]] > > runs p xs = ... > > > > which produces a list of runs, i.e. the first result is that prefix of > > xs, such that for all consecutive elements e_i, e_{i+1}, the property > > holds, i.e. p e_i e_{i+1} -->> True. > > We already have something like that: > > groupBy :: (a -> a -> Bool) -> [a] -> [[a]] The groupBy function compares the first element e_1 to all consecutive elements e_i until it finds one for which the predicate doesn't hold. The runs function compares *consecutive* elements e_i and e_{i+1}. By example: > runs (<) [1,2,3,4,3,4,5] [[1,2,3,4],[3,4,5]] > In fact, instead of spans and breaks, why not just use: > > runs :: (a -> Bool) -> [a] -> [[a]] > runs = groupBy . on (==) groupBy . on (==) :: (a -> ()) -> [a] -> [[a]] > Then we have: > > breaks p = runs p . dropWhile p > spans p = runs p . dropWhile (not . p) For spans and breaks there might be a composition of functions already in Data.List, but because of the above type check failure, it's not this. Also, runs is more general than spans and breaks and runs is actually more sorely missed. I may still be mistaken, but there are no functions in Data.List that allow predicates on *consecutive* list elements. Regards, Philip From p.k.f.holzenspies at utwente.nl Thu Nov 19 09:10:16 2009 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?ISO-8859-1?Q?H=F6lzenspies?=) Date: Thu Nov 19 08:45:32 2009 Subject: Proposal (Trac ticket #3671): Add takeRec, genericTakeRec and spanRec to Data.List In-Reply-To: <1258639332.7681.75.camel@ewi1043> References: <1258465664.2704.6.camel@ewi1043> <20091117143517.GA443@matrix.chaos.earth.li> <2608b8a80911181442k1525eb1r1fc5b2ef32d7ecc5@mail.gmail.com> <884298590.20091119062849@gmail.com> <1258627651.7681.62.camel@ewi1043> <2608b8a80911190328g3a43ad2eoedbdded5bf1f349@mail.gmail.com> <1258639332.7681.75.camel@ewi1043> Message-ID: <1258639816.7681.80.camel@ewi1043> On Thu, 2009-11-19 at 15:02 +0100, Philip K.F. H?lzenspies wrote: > > runs :: (a -> Bool) -> [a] -> [[a]] > > runs = groupBy . on (==) > > groupBy . on (==) :: (a -> ()) -> [a] -> [[a]] Don't know what neuron misfired there... my apologies. I quickly tried it out in ghci: > let runs' = groupBy . on (==) > :t runs' x :: (a -> ()) -> [a] -> [[a]] but of course: > :t groupBy . on (==) groupBy . on (==) :: (Eq b) => (a -> b) -> [a] -> [[a]] My bad. However, runs is still considerably more general and, AFAICT, not a composition of other Data.List functions. I agree with Ian that even if it took us a while to write those compositions properly, they shouldn't be in the library. I stand by runs, though ;) Regards, Philip From matt at mattcox.ca Fri Nov 20 02:19:03 2009 From: matt at mattcox.ca (Matthew William Cox) Date: Fri Nov 20 01:54:23 2009 Subject: Cabal and Hsc2hs Build Phase Options Message-ID: <20091120071903.GA9057@neptune.mattcox.ca> Hello, Firstly, is there any way to specify (statically) options to be passed to Hsc2hs to be used during the build phase? Ideally, extending the --$PROGNAME-options command line argument to a cabal directive would be ideal, so that hsc2hs-options: would be a valid directory for use in .buildinfo/.cabal files. Is there a way to specificy the compiler and linker to be used in the invocation of hsc2hs? Secondly, there is a problem with how command line arguments are passed to hsc2hs. Running build with the command line argument: --hsc2hs-options="--cc=mpicc --ld=mpicc" -v yields the following call to hsc2hs: > Creating dist/build/dllg/dllg-tmp/System (and its parents) > /usr/bin/hsc2hs --cc=mpicc -ld=mpicc --cc=/usr/bin/gcc --ld=/usr/bin/gcc --cflag=-D__G... Two compilers and two linkers are passed to Hsc2hs, but the later arguments (the default compilers) take precedence, as can be seen if the /bin/false is passed instead of mpicc. Cheers, Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20091120/a102bfbb/attachment.bin From duncan.coutts at googlemail.com Fri Nov 20 05:00:10 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Fri Nov 20 04:35:31 2009 Subject: Cabal and Hsc2hs Build Phase Options In-Reply-To: <20091120071903.GA9057@neptune.mattcox.ca> References: <20091120071903.GA9057@neptune.mattcox.ca> Message-ID: <1258711210.4896.25599.camel@localhost> On Fri, 2009-11-20 at 02:19 -0500, Matthew William Cox wrote: > Hello, > > Firstly, is there any way to specify (statically) options to be passed > to Hsc2hs to be used during the build phase? Ideally, extending the > --$PROGNAME-options command line argument to a cabal directive would be > ideal, so that hsc2hs-options: would be a valid directory for use in > .buildinfo/.cabal files. Is there a way to specificy the compiler and > linker to be used in the invocation of hsc2hs? No, and that is by design. There is a balance between things we let package authors decide and things we let package builders decide. This is to match the situation in the open source world where the two are different people. I realise the division can be a bit confusing for in-house projects where the two roles are taken by the same individual. The builder is in a position to know if special flags are needed. Also, since the builder controls the build environment they could use special flags anyway by changing the $PATH and using wrapper scripts, so there's no point in not letting the builder do what they want. > Secondly, there is a problem with how command line arguments are > passed to hsc2hs. Running build with the command line argument: > --hsc2hs-options="--cc=mpicc --ld=mpicc" -v > yields the following call to hsc2hs: > > > Creating dist/build/dllg/dllg-tmp/System (and its parents) > > /usr/bin/hsc2hs --cc=mpicc -ld=mpicc --cc=/usr/bin/gcc --ld=/usr/bin/gcc --cflag=-D__G... > > Two compilers and two linkers are passed to Hsc2hs, but the later > arguments (the default compilers) take precedence, as can be seen if the > /bin/false is passed instead of mpicc. Right. So I can certainly see that there's a use case for putting the extra flags at the end, to override. I'm not entirely sure whether we also have cases where they really need to be at the beginning. If so we'd need two ways of setting program flags. Now I take it that you really want to use your mpicc just for hsc2hs and not for all cases where cabal (or programs that cabal calls) call gcc right? I ask because we've got another open feature request ticket that asks that cabal --with-gcc=blah should pass that gcc on to ghc, hsc2hs, etc etc. I suggest you file a ticket with this feature request. If you want it sorted out quickly however you'll have to do a little testing work. I suggest starting with this patch (against Cabal HEAD) and seeing if that sorts out the problem, and if it creates any other obvious problems. hunk ./Distribution/Simple/Program/Run.hs 67 -programInvocation prog extraArgs = +programInvocation prog args = hunk ./Distribution/Simple/Program/Run.hs 70 - progInvokeArgs = programArgs prog ++ extraArgs + progInvokeArgs = args ++ programArgs prog BTW, as a short-term workaround you can always use the wrapper script trick: --with-hsc2hs=hsc2hs.sh Duncan From matt at mattcox.ca Fri Nov 20 09:47:58 2009 From: matt at mattcox.ca (Matthew William Cox) Date: Fri Nov 20 09:23:17 2009 Subject: Cabal and Hsc2hs Build Phase Options In-Reply-To: <1258711210.4896.25599.camel@localhost> References: <20091120071903.GA9057@neptune.mattcox.ca> <1258711210.4896.25599.camel@localhost> Message-ID: <20091120144758.GB20012@neptune.mattcox.ca> On Fri, Nov 20, 2009 at 10:00:10AM +0000, Duncan Coutts wrote: > The builder is in a position to know if special flags are needed. Also, > since the builder controls the build environment they could use special > flags anyway by changing the $PATH and using wrapper scripts, so there's > no point in not letting the builder do what they want. The author is also in a position to know that the same flags need to be used in two different build phases. In this case, I'm using autoconfUserHooks to find out how to use the system's MPI library. A builder should direct the autoconf script to the correct library (if there are multiple) using an environment variable. In either case, autoconf hands me a compiler wrapper which needs to be used to compile and link all C code (and the FFI using code). There's no other portable way to use MPI, like pkgconfig or whathaveyou to suss out the magic CFLAGS and LDFLAGS needed. Anyways, from my perspective as an author that wants to provide the simplist building experience for someone else, I'd rather be able to tell them in the docs to run runhaskell Setup.hs configure && runhaskell Setup.hs build rather than to 1) runhaskell Setup.hs configure, 2) read the generated buildinfo script to determine the compiler and linker passed to ghc, 3) call runhaskell Setup.hs build --hsc2hs-options="-cc=$COMPILER --ld=$COMPILER" where $COMPILER is the exact compiler wrapper used by Ghc, and failing to do this may result in failure or having a schizophrenic build compiled against one library and linked against another. The user arguments at the command line should always override the ones in a configuration file of course. That gets you the best of both worlds. tl;dr: you can have your cake and eat it too if the user's command line arguments always override the equivalent configuration file directive. > Now I take it that you really want to use your mpicc just for hsc2hs and > not for all cases where cabal (or programs that cabal calls) call gcc > right? I ask because we've got another open feature request ticket that > asks that cabal --with-gcc=blah should pass that gcc on to ghc, hsc2hs, > etc etc. I need it for all phases of the build (GHC, hsc2hs, etc.) Right now, it's override GHC using ghc-options: -pgmc ... -pgml ... but it would be even better if there was one central way. Again, a --with-linker would be nice to add, and especially, a configuration file directive to set it statically based on an autoconf check with the option to be overridden by a user's command line arguments. > BTW, as a short-term workaround you can always use the wrapper script > trick: --with-hsc2hs=hsc2hs.sh I take it there's no way of doing this statically? Thanks, Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20091120/77a8c497/attachment.bin From Christian.Maeder at dfki.de Fri Nov 20 12:45:09 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Nov 20 12:20:29 2009 Subject: Proposal (Trac ticket #3671): Add takeRec, genericTakeRec and spanRec to Data.List In-Reply-To: <1258639816.7681.80.camel@ewi1043> References: <1258465664.2704.6.camel@ewi1043> <20091117143517.GA443@matrix.chaos.earth.li> <2608b8a80911181442k1525eb1r1fc5b2ef32d7ecc5@mail.gmail.com> <884298590.20091119062849@gmail.com> <1258627651.7681.62.camel@ewi1043> <2608b8a80911190328g3a43ad2eoedbdded5bf1f349@mail.gmail.com> <1258639332.7681.75.camel@ewi1043> <1258639816.7681.80.camel@ewi1043> Message-ID: <4B06D5A5.9080309@dfki.de> My proposal would be to add a function like \begin{code} replaceBy :: ([a] -> (b, [a])) -> [a] -> [b] replaceBy splt l = case l of [] -> [] _ -> let (ft, rt) = splt l in ft : replaceBy splt rt \end{code} that takes a function "splt" that splits a non-empty list and returns a shorter list as second component (to ensure termination). I've used this function to implement a replace function (below), but the simplest application is: \begin{code} splitAts :: Int -> [a] -> [[a]] splitAts n | n > 0 = replaceBy (splitAt n) \end{code} or with Control.Applicative: \begin{code} breaks :: (a -> Bool) -> [a] -> [[a]] breaks p = replaceBy $ second (drop 1) . break p \end{code} This "breaks" function ignores a final separator! breaks (',' ==) "123,456,,78" == ["123","456","","78"] breaks (',' ==) "123,456,78," == ["123","456","78"] groupBy could be implemented as follows: \begin{code} groupBy eq = replaceBy $ \ (h : r) -> first (h :) $ span (eq h) r \end{code} And given a function to split of a single "run", "runs" (with the same type as groupBy) is simply: \begin{code} runs :: (a -> a -> Bool) -> [a] -> [[a]] runs eq = replaceBy (run eq) run :: (a -> a -> Bool) -> [a] -> ([a], [a]) run eq l = case l of x : r@(y : s) | eq x y -> first (x :) $ run eq r x : r -> ([x], r) [] -> ([], []) \end{code} My original application for replacing a substring by a special character is defined by: \begin{code} replace :: Eq a => [a] -> a -> [a] -> [a] replace sl@(_ : _) r = replaceBy $ \ l@(hd : tl) -> case stripPrefix sl l of Nothing -> (hd, tl) Just rt -> (r, rt) \end{code} Cheers Christian From jules at jellybean.co.uk Mon Nov 23 06:54:52 2009 From: jules at jellybean.co.uk (Jules Bean) Date: Mon Nov 23 06:30:06 2009 Subject: Proposal (Trac ticket #3671): Add takeRec, genericTakeRec and spanRec to Data.List In-Reply-To: <4B06D5A5.9080309@dfki.de> References: <1258465664.2704.6.camel@ewi1043> <20091117143517.GA443@matrix.chaos.earth.li> <2608b8a80911181442k1525eb1r1fc5b2ef32d7ecc5@mail.gmail.com> <884298590.20091119062849@gmail.com> <1258627651.7681.62.camel@ewi1043> <2608b8a80911190328g3a43ad2eoedbdded5bf1f349@mail.gmail.com> <1258639332.7681.75.camel@ewi1043> <1258639816.7681.80.camel@ewi1043> <4B06D5A5.9080309@dfki.de> Message-ID: <4B0A780C.5070300@jellybean.co.uk> Christian Maeder wrote: > My proposal would be to add a function like > > \begin{code} > replaceBy :: ([a] -> (b, [a])) -> [a] -> [b] > replaceBy splt l = case l of > [] -> [] > _ -> let (ft, rt) = splt l in > ft : replaceBy splt rt > \end{code} > > that takes a function "splt" that splits a non-empty list and returns a > shorter list as second component (to ensure termination). > .... if we're in the business of proposing generalised search and replace I'd like to propose this one: http://haskell.org/pipermail/haskell-cafe/2007-July/028032.html which is along the general lines above but slightly more general. When I made that posting in 2007 I was hoping for name suggestions. In the absence of anythign better I suggest 'Data.List.transform' or the more whimsical 'Data.List.transmogrify'. I would also suggest a convenience function 'Data.List.replace' defined from it in the obvious way. I am also in agreement with 'groupsOf' (which I sometimes called 'chunksOf' but I like both names) proposed by Yitzchak. Will all that in mind I oppose this proposal, because whilst I fully support filling in some gaps in Data.List I don't think these are the best primitives. Jules From valery.vv at gmail.com Mon Nov 23 07:27:36 2009 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Mon Nov 23 07:03:16 2009 Subject: #562: cabal-install update fails going through a HTTP proxy In-Reply-To: References: <87ab0rc475.fsf@gmail.com> <4AB487F0.5040207@gmail.com> <4AFF2AC3.8020403@gmail.com> <4B01531E.8050804@gmail.com> Message-ID: On Mon, Nov 16, 2009 at 11:15 PM, Valery V. Vorotyntsev wrote: > Cabal client reinstalled with "patched" HTTP-4000.0.8 was still having > occasional failures today. My proxy-POC.hs always succeeded, while > cabal failed quite often with familiar > > cabal: Codec.Compression.Zlib: premature end of compressed stream > > This means that proxy-POC.hs is not trustworthy: it doesn't expose the > bug in 100% cases. > > I am going to roll back even further tomorrow: I'll patch [1] > cabal-install to use strict ByteStrings and see if /that/ does the > job. (I'm not sure in anything any more.) > > [1] http://hpaste.org/fastcgi/hpaste.fcgi/view?id=9447#a9504 Strict bytestrings in cabal-install do the job, yes. > I've installed squid proxy server. Gotta make this bug exposable... Downloading through local squid did not manifest the bug. * * * Sigbjorn, I am stuck. If you have some idea on how to pursue this bug (print debugging with Debug.Trace?), I'll be delighted to test it. The bug is reproducible from within office LAN (read: ``business hours, 8 am to 16 pm UTC''): $ cabal update -v3 Downloading the latest package list from hackage.haskell.org Sending: GET http://hackage.haskell.org/packages/archive/00-index.tar.gz HTTP/1.1 Proxy-Authorization: Basic SG93IGFyZSB5b3U/ User-Agent: cabal-install/0.6.2 Host: hackage.haskell.org proxy uri host: xproxy, port: :3128 Creating new connection to xproxy:3128 Received: HTTP/1.0 200 OK Date: Mon, 23 Nov 2009 12:15:23 GMT Server: Apache/2.2.3 (Debian) Last-Modified: Mon, 23 Nov 2009 01:21:45 GMT ETag: "388dda-141754-a6117c40" Accept-Ranges: bytes Content-Length: 1316692 Content-Type: application/x-tar Content-Encoding: x-gzip X-Cache: MISS from xproxy.foo.bar.ua X-Cache-Lookup: MISS from xproxy.foo.bar.ua:3128 Via: 1.1 xproxy.foo.bar.ua:3128 (squid/2.7.STABLE6) Connection: close Downloaded to /home/vvv/.cabal/packages/hackage.haskell.org/00-index.tar.gz cabal: Codec.Compression.Zlib: premature end of compressed stream Have fun! -- vvv From valery.vv at gmail.com Mon Nov 23 07:27:36 2009 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Mon Nov 23 07:03:18 2009 Subject: #562: cabal-install update fails going through a HTTP proxy In-Reply-To: References: <87ab0rc475.fsf@gmail.com> <4AB487F0.5040207@gmail.com> <4AFF2AC3.8020403@gmail.com> <4B01531E.8050804@gmail.com> Message-ID: On Mon, Nov 16, 2009 at 11:15 PM, Valery V. Vorotyntsev wrote: > Cabal client reinstalled with "patched" HTTP-4000.0.8 was still having > occasional failures today. My proxy-POC.hs always succeeded, while > cabal failed quite often with familiar > > cabal: Codec.Compression.Zlib: premature end of compressed stream > > This means that proxy-POC.hs is not trustworthy: it doesn't expose the > bug in 100% cases. > > I am going to roll back even further tomorrow: I'll patch [1] > cabal-install to use strict ByteStrings and see if /that/ does the > job. (I'm not sure in anything any more.) > > [1] http://hpaste.org/fastcgi/hpaste.fcgi/view?id=9447#a9504 Strict bytestrings in cabal-install do the job, yes. > I've installed squid proxy server. Gotta make this bug exposable... Downloading through local squid did not manifest the bug. * * * Sigbjorn, I am stuck. If you have some idea on how to pursue this bug (print debugging with Debug.Trace?), I'll be delighted to test it. The bug is reproducible from within office LAN (read: ``business hours, 8 am to 16 pm UTC''): $ cabal update -v3 Downloading the latest package list from hackage.haskell.org Sending: GET http://hackage.haskell.org/packages/archive/00-index.tar.gz HTTP/1.1 Proxy-Authorization: Basic SG93IGFyZSB5b3U/ User-Agent: cabal-install/0.6.2 Host: hackage.haskell.org proxy uri host: xproxy, port: :3128 Creating new connection to xproxy:3128 Received: HTTP/1.0 200 OK Date: Mon, 23 Nov 2009 12:15:23 GMT Server: Apache/2.2.3 (Debian) Last-Modified: Mon, 23 Nov 2009 01:21:45 GMT ETag: "388dda-141754-a6117c40" Accept-Ranges: bytes Content-Length: 1316692 Content-Type: application/x-tar Content-Encoding: x-gzip X-Cache: MISS from xproxy.foo.bar.ua X-Cache-Lookup: MISS from xproxy.foo.bar.ua:3128 Via: 1.1 xproxy.foo.bar.ua:3128 (squid/2.7.STABLE6) Connection: close Downloaded to /home/vvv/.cabal/packages/hackage.haskell.org/00-index.tar.gz cabal: Codec.Compression.Zlib: premature end of compressed stream Have fun! -- vvv From marlowsd at gmail.com Mon Nov 23 10:47:58 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 23 10:23:29 2009 Subject: ANNOUNCE: deepseq-1.0.0.0 In-Reply-To: <4B053767.8060201@gmail.com> References: <4B028245.1080201@gmail.com> <4B03BBAB.2090006@gmail.com><20091118121244.GA22164@matrix.chaos.earth.li> <4B052DAC.9060405@gmail.com> <2608b8a80911190345u4887e0b7r9d23d98186621a46@mail.gmail.com> <16442B752A06A74AB4D9F9A5FF076E4B03B9FCD2@ELON17P32001A.csfb.cs-group.com> <4B053767.8060201@gmail.com> Message-ID: <4B0AAEAE.8090104@gmail.com> On 19/11/09 12:17, Simon Marlow wrote: > Ok, unless there are any further objections, I'll change the names back to > > class NFData a where > rnf :: a -> () > > and also add > > deepseq :: a -> b -> b > > but I'll leave the module name as Control.DeepSeq. I made this change and uploaded deepseq-1.1.0.0 on Friday. There's also an updated parallel-2.1.0.0, but after discussions with Phil Trinder and other Parallel Haskell gurus, I think there may be further changes forthcoming. Upshot: the new version of parallel is still changing, you might want to wait until things settle down (hopefully not long) before switching. Cheers, Simon From ndmitchell at gmail.com Mon Nov 23 12:42:39 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Nov 23 12:17:56 2009 Subject: Fwd: Network on GHC 6.12 with Windows In-Reply-To: <0319C4ED2AB1064491EC6A53F1B1556B06B1485B@UKWATXMB101V.zone1.scb.net> References: <0319C4ED2AB1064491EC6A53F1B1556B06B1485B@UKWATXMB101V.zone1.scb.net> Message-ID: <404396ef0911230942m72de3960w826a1a424c707c1b@mail.gmail.com> Hi Johan, I just tried compiling network-2.2.1.5 with GHC 6.12.1rc2 on Windows, under Cygwin. The failures I got were: $ runhaskell Setup build Setup.hs:3:0: ? ?Warning: In the use of `defaultUserHooks' ? ? ? ? ? ? (imported from Distribution.Simple): ? ? ? ? ? ? Deprecated: "Use simpleUserHooks or autoconfUserHooks, unless you need Cabal-1.2 ? ? ? ? ? ? compatibility in which case you must stick with defaultUserHooks" Preprocessing library network-2.2.1.5... Network\Socket.hsc: In function `main': Network\Socket.hsc:994: error: invalid application of `sizeof' to incomplete type `ucred' Network\Socket.hsc:994: error: invalid application of `sizeof' to incomplete type `ucred' Network\Socket.hsc:994: error: invalid application of `sizeof' to incomplete type `ucred' Network\Socket.hsc:999: error: `SO_PEERCRED' undeclared (first use in this function) Network\Socket.hsc:999: error: (Each undeclared identifier is reported only once Network\Socket.hsc:999: error: for each function it appears in.) Network\Socket.hsc:1000: error: dereferencing pointer to incomplete type Network\Socket.hsc:1001: error: dereferencing pointer to incomplete type Network\Socket.hsc:1002: error: dereferencing pointer to incomplete type compiling dist\build\Network\Socket_hsc_make.c failed command was: C:\ghc\ghc-6.12.1-rc2\mingw\bin\gcc.exe -c -D__GLASGOW_HASKELL__=612 -Iinclude -DCALLCONV=ccall -DBASE4 -IC:\ghc\ghc-6.12.1-rc2\base-4.2.0.0\include -IC:\ghc\ghc-6.12.1-rc2/include -IC:\ghc\ghc-6.12.1-rc2/include -IC:/ghc/ghc-6.12.1-rc2/lib/include/ dist\build\Network\Socket_hsc_make.c -o dist\build\Network\Socket_hsc_make.o I then tried the darcs version and got: $ runhaskell Setup configure Setup.hs:3:0: ? ?Warning: In the use of `defaultUserHooks' ? ? ? ? ? ? (imported from Distribution.Simple): ? ? ? ? ? ? Deprecated: "Use simpleUserHooks or autoconfUserHooks, unless you need Cabal-1.2 ? ? ? ? ? ? compatibility in which case you must stick with defaultUserHooks" Warning: defaultUserHooks in Setup script is deprecated. Configuring network-2.2.1.5... configure: WARNING: unrecognized options: --with-hc checking build system type... i686-pc-cygwin checking host system type... i686-pc-cygwin checking for gcc... gcc checking for C compiler default output file name... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for an ANSI C-conforming const... yes checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking for stdlib.h... (cached) yes checking for sys/types.h... (cached) yes checking for unistd.h... (cached) yes checking winsock2.h usability... no checking winsock2.h presence... yes configure: WARNING: winsock2.h: present but cannot be compiled configure: WARNING: winsock2.h: ? ? check for missing prerequisite headers? configure: WARNING: winsock2.h: see the Autoconf documentation configure: WARNING: winsock2.h: ? ? section "Present But Cannot Be Compiled" configure: WARNING: winsock2.h: proceeding with the compiler's result configure: WARNING: ? ? ## ------------------------------------ ## configure: WARNING: ? ? ## Report this to libraries@haskell.org ## configure: WARNING: ? ? ## ------------------------------------ ## checking for winsock2.h... no checking ws2tcpip.h usability... no checking ws2tcpip.h presence... yes configure: WARNING: ws2tcpip.h: present but cannot be compiled configure: WARNING: ws2tcpip.h: ? ? check for missing prerequisite headers? configure: WARNING: ws2tcpip.h: see the Autoconf documentation configure: WARNING: ws2tcpip.h: ? ? section "Present But Cannot Be Compiled" configure: WARNING: ws2tcpip.h: proceeding with the compiler's result configure: WARNING: ? ? ## ------------------------------------ ## configure: WARNING: ? ? ## Report this to libraries@haskell.org ## configure: WARNING: ? ? ## ------------------------------------ ## checking for ws2tcpip.h... no checking wspiapi.h usability... no checking wspiapi.h presence... no checking for wspiapi.h... no checking arpa/inet.h usability... yes checking arpa/inet.h presence... yes checking for arpa/inet.h... yes checking netdb.h usability... yes checking netdb.h presence... yes checking for netdb.h... yes checking netinet/in.h usability... yes checking netinet/in.h presence... yes checking for netinet/in.h... yes checking netinet/tcp.h usability... yes checking netinet/tcp.h presence... yes checking for netinet/tcp.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking sys/uio.h usability... yes checking sys/uio.h presence... yes checking for sys/uio.h... yes checking sys/un.h usability... yes checking sys/un.h presence... yes checking for sys/un.h... yes checking for readlink... yes checking for symlink... yes checking for struct msghdr.msg_control... yes checking for struct msghdr.msg_accrights... no checking for struct sockaddr.sa_len... no checking for in_addr_t in netinet/in.h... yes checking for SO_PEERCRED and struct ucred in sys/socket.h... yes checking for _head_libws2_32_a in -lws2_32... yes checking for getaddrinfo... no checking for getaddrinfo if WINVER is 0x0501... no checking for gai_strerror... no checking whether AI_ADDRCONFIG is declared... no checking whether AI_ALL is declared... no checking whether AI_NUMERICSERV is declared... no checking whether AI_V4MAPPED is declared... no checking for sendfile in sys/sendfile.h... no checking for sendfile in sys/socket.h... no checking for gethostent... no configure: creating ./config.status config.status: creating network.buildinfo config.status: creating include/HsNetworkConfig.h configure: WARNING: unrecognized options: --with-hc Setup: Missing dependency on a foreign library: * Missing header file: HsNet.h This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. I was really hoping for a Network package on GHC 6.12, as lots of my stuff depends (indirectly) on it. Is there anything I can do to help? Thanks, Neil From johan.tibell at gmail.com Mon Nov 23 14:59:20 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon Nov 23 14:34:48 2009 Subject: Network on GHC 6.12 with Windows In-Reply-To: <404396ef0911230942m72de3960w826a1a424c707c1b@mail.gmail.com> References: <0319C4ED2AB1064491EC6A53F1B1556B06B1485B@UKWATXMB101V.zone1.scb.net> <404396ef0911230942m72de3960w826a1a424c707c1b@mail.gmail.com> Message-ID: <90889fe70911231159q3016b094pd38b44cf476b8360@mail.gmail.com> Hi Neil, On Mon, Nov 23, 2009 at 6:42 PM, Neil Mitchell wrote: > Hi Johan, > > I just tried compiling network-2.2.1.5 with GHC 6.12.1rc2 on Windows, > under Cygwin. The failures I got were: > > [snip] > > I was really hoping for a Network package on GHC 6.12, as lots of my > stuff depends (indirectly) on it. Is there anything I can do to help? Bryan accepted the following ticket that seems to match your error: http://trac.haskell.org/network/ticket/20 Perhaps you could see if you could help him in some way. Adding extra information that could explain why we see a difference between the two GHC versions would be a great start. Cheers, Johan From Christian.Maeder at dfki.de Tue Nov 24 04:23:48 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Nov 24 03:58:55 2009 Subject: Proposal (Trac ticket #3671): Add takeRec, genericTakeRec and spanRec to Data.List In-Reply-To: <4B0A780C.5070300@jellybean.co.uk> References: <1258465664.2704.6.camel@ewi1043> <20091117143517.GA443@matrix.chaos.earth.li> <2608b8a80911181442k1525eb1r1fc5b2ef32d7ecc5@mail.gmail.com> <884298590.20091119062849@gmail.com> <1258627651.7681.62.camel@ewi1043> <2608b8a80911190328g3a43ad2eoedbdded5bf1f349@mail.gmail.com> <1258639332.7681.75.camel@ewi1043> <1258639816.7681.80.camel@ewi1043> <4B06D5A5.9080309@dfki.de> <4B0A780C.5070300@jellybean.co.uk> Message-ID: <4B0BA624.6010202@dfki.de> Ok, lets try to get back to the proposal. 1. We want something like takeRec being named splitAts or groupsOf (groupsOf is too similar to the existing groupsBy) 2. genericTakeRec is just a variant of takeRec based on genericSplitAt rather than splitAt (or genericTake, genericDrop instead of take, drop) 3. spanRec changed to a mutual recursive implementation for spans and breaks (in the ticket) that is not supported much. Rather breaks was more discussed in this thread as a splitting function (that was discussed years before under splitBy or splitOn without any agreement.) Agreement seems to be about "breaks p = spans (not . p)" (or vice versa) Furthermore, proposal for runs (4.) and replace (5.) came up in this thread, that are not part of the ticket. 4. I find "runs" useful in the sense proposed by Philip with type runs :: (a -> a -> Bool) -> [a] -> [[a]] > runs (<) [1,2,3,4,3,4,5] [[1,2,3,4],[3,4,5]] (there's no proposal to rename groupsBy) 5. The type of my replace function was: replace :: Eq a => [a] -> a -> [a] -> [a] and a (reasonable) alternative would be to replace a sublist by another sublist and not by a single element. Which of the above functions (1. - 4.) should be part of the proposal? How should these functions be implemented? I only made a proposal how they could be implemented using replaceBy (below), but direct recursive definitions may be more appropriate. I.e. unlines and unwords are also defined with explicit recursion although alternative definitions are there (based on concatMap and foldr1) Cheers Christian Jules Bean schrieb: > Christian Maeder wrote: >> My proposal would be to add a function like >> >> \begin{code} >> replaceBy :: ([a] -> (b, [a])) -> [a] -> [b] >> replaceBy splt l = case l of >> [] -> [] >> _ -> let (ft, rt) = splt l in >> ft : replaceBy splt rt >> \end{code} >> >> that takes a function "splt" that splits a non-empty list and returns a >> shorter list as second component (to ensure termination). >> > > .... if we're in the business of proposing generalised search and > replace I'd like to propose this one: > > http://haskell.org/pipermail/haskell-cafe/2007-July/028032.html > > which is along the general lines above but slightly more general. It's more special in the sense that the result list cannot be "[[a]]" as required for all the above functions except replace. > When I made that posting in 2007 I was hoping for name suggestions. In > the absence of anythign better I suggest 'Data.List.transform' or the > more whimsical 'Data.List.transmogrify'. > > I would also suggest a convenience function 'Data.List.replace' defined > from it in the obvious way. > > I am also in agreement with 'groupsOf' (which I sometimes called > 'chunksOf' but I like both names) proposed by Yitzchak. > > Will all that in mind I oppose this proposal, because whilst I fully > support filling in some gaps in Data.List I don't think these are the > best primitives. > > Jules From ganesh.sittampalam at credit-suisse.com Tue Nov 24 05:26:56 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Tue Nov 24 05:02:14 2009 Subject: Could iteratee depend on mtl instead of transformers? In-Reply-To: <20091119002838.GA25218@soi.city.ac.uk> References: <20091117124208.ffeb0a35.mle+hs@mega-nerd.com><7fb8f82f0911162003x6ec712caw8c2c4f7a53dc0680@mail.gmail.com><1258445961-sup-4987@peray><29bf512f0911170456h7871a981tc49560b936640c@mail.gmail.com><7fb8f82f0911170609r3bc24d82ic771e395ed414d72@mail.gmail.com><20091117160430.GA14545@soi.city.ac.uk><7fb8f82f0911171633l260390ddj221ef938474f3590@mail.gmail.com><20091118005719.GA26862@soi.city.ac.uk><1258567464.4896.14664.camel@localhost> <20091119002838.GA25218@soi.city.ac.uk> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B03B9FD02@ELON17P32001A.csfb.cs-group.com> Ross Paterson wrote: > But there's a problem: > even if we rename the modules in monads-fd, we still have two modules > in transformers that have the same names as modules in mtl, namely > Control.Monad.Identity and Control.Monad.Trans. Renaming isn't an > option: at least the first of those is the Right Name for the module > concerned. People who build with cabal are fine: only the dependent > packages are exposed, and all packages use the same type > constructors, so the interfaces are compatible. But people who build > with ghci or ghc --make will get the error message at the top of this > thread: > > Could not find module `Control.Monad.Identity': > it was found in multiple packages: mtl-2.0 transformers-0.1.4.0 This is annoying, but can be worked around with -hide-package. We could also deprecate mtl as part of the migration, encouraging people to move away from it as quickly as possible. After a bit it could be removed from the platform, which would mean that people would only end up with it on their systems if they install it or something that still depends on it. > So I think we're back at the original plan: a big bang replacement of > dependencies on mtl with dependencies on transformers and monads-fd. I'd still favour doing things more gradually. > (Unless we introduce virtual packages.) What functionality would virtual packages have? Presumably in this instance they'd need to provide some mechanism for GHC to recognise that you get the same result by importing the modules from either source. Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From marlowsd at gmail.com Tue Nov 24 06:00:09 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Nov 24 05:35:23 2009 Subject: export toDescList from Data.Map In-Reply-To: <2518b95d0910112038u11e883b2ka61188b78aab0d18@mail.gmail.com> References: <2518b95d0809081546y42f85696h694c1003e82dc5de@mail.gmail.com> <2518b95d0910112038u11e883b2ka61188b78aab0d18@mail.gmail.com> Message-ID: <4B0BBCB9.8050506@gmail.com> On 12/10/2009 04:38, Evan Laforge wrote: > On Mon, Sep 8, 2008 at 3:46 PM, Evan Laforge wrote: >> So, I mentioned this a long time ago but didn't get any responses and >> then I got distracted. So this time I added a ticket and patch and >> everything: 2580 > > Sorry to dredge this one up again, but this patch was apparently > applied more than a year ago, and yet when I look at the latest > version 0.2.0.1 of containers on hackage, uploaded on April 2009, the > changes aren't in the haddock (searching for toDescList reveals > nothing). I was hoping to be able to finally remove my local hack! > > Was the patch applied? What's going on? Will 6.12 include it? Yes, 6.12.1 includes that patch. Cheers, Simon From ross at soi.city.ac.uk Tue Nov 24 07:30:08 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Nov 24 07:05:16 2009 Subject: Could iteratee depend on mtl instead of transformers? In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B03B9FD02@ELON17P32001A.csfb.cs-group.com> References: <7fb8f82f0911162003x6ec712caw8c2c4f7a53dc0680@mail.gmail.com> <1258445961-sup-4987@peray> <29bf512f0911170456h7871a981tc49560b936640c@mail.gmail.com> <7fb8f82f0911170609r3bc24d82ic771e395ed414d72@mail.gmail.com> <20091117160430.GA14545@soi.city.ac.uk> <7fb8f82f0911171633l260390ddj221ef938474f3590@mail.gmail.com> <20091118005719.GA26862@soi.city.ac.uk> <1258567464.4896.14664.camel@localhost> <20091119002838.GA25218@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B03B9FD02@ELON17P32001A.csfb.cs-group.com> Message-ID: <20091124123008.GA8667@soi.city.ac.uk> On Tue, Nov 24, 2009 at 10:26:56AM -0000, Sittampalam, Ganesh wrote: > Ross Paterson wrote: > > Could not find module `Control.Monad.Identity': > > it was found in multiple packages: mtl-2.0 transformers-0.1.4.0 > > This is annoying, but can be worked around with -hide-package. We could > also deprecate mtl as part of the migration, encouraging people to move > away from it as quickly as possible. After a bit it could be removed > from the platform, which would mean that people would only end up with > it on their systems if they install it or something that still depends > on it. So the proposal is that HP should contain mtl-2.0, monads-fd and transformers, but with mtl hidden. Could the HP do that? > > (Unless we introduce virtual packages.) > > What functionality would virtual packages have? Presumably in this > instance they'd need to provide some mechanism for GHC to recognise that > you get the same result by importing the modules from either source. I was imagining something that would be implemented in Cabal, so you could say somewhere something like mtl >= 2 = transformers > 0.1.4.0, monads-fd >= 0.0.0.1 and Cabal would build packages with an unversioned dependency on mtl using the other two instead. That would still leave old versions of mtl needing hiding, though. From johan.tibell at gmail.com Tue Nov 24 08:56:40 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue Nov 24 08:32:06 2009 Subject: Network on GHC 6.12 with Windows In-Reply-To: <90889fe70911231159q3016b094pd38b44cf476b8360@mail.gmail.com> References: <0319C4ED2AB1064491EC6A53F1B1556B06B1485B@UKWATXMB101V.zone1.scb.net> <404396ef0911230942m72de3960w826a1a424c707c1b@mail.gmail.com> <90889fe70911231159q3016b094pd38b44cf476b8360@mail.gmail.com> Message-ID: <90889fe70911240556j63627855u4935748d0f63827b@mail.gmail.com> Neil, Could you please try Ron's patch linked from http://trac.haskell.org/network/ticket/20#comment:5 Cheers, Johan From ndmitchell at gmail.com Tue Nov 24 10:40:08 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Nov 24 10:15:16 2009 Subject: Network on GHC 6.12 with Windows In-Reply-To: <90889fe70911240556j63627855u4935748d0f63827b@mail.gmail.com> References: <0319C4ED2AB1064491EC6A53F1B1556B06B1485B@UKWATXMB101V.zone1.scb.net> <404396ef0911230942m72de3960w826a1a424c707c1b@mail.gmail.com> <90889fe70911231159q3016b094pd38b44cf476b8360@mail.gmail.com> <90889fe70911240556j63627855u4935748d0f63827b@mail.gmail.com> Message-ID: <404396ef0911240740n30825fdakd204bbb9ef363690@mail.gmail.com> Hi Johan, I get a different behaviour, but it's not all good. I seem to fail during the configure stage now - complete output below. Thanks, Neil $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.12.0.20091121 $ darcs get http://code.haskell.org/network Copying patch 329 of 329... done. Applying patch 329 of 329... done. Finished getting. $ cd network $ wget http://johantibell.com/gamr7networkpatch.dpatch --2009-11-24 15:32:54-- http://johantibell.com/gamr7networkpatch.dpatch Length: 3178 (3.1K) [application/octet-stream] Saving to: `gamr7networkpatch.dpatch' 100%[======================================>] 3,178 --.-K/s in 0.002s 2009-11-24 15:32:54 (1.60 MB/s) - `gamr7networkpatch.dpatch' saved [3178/3178] $ darcs apply gamr7networkpatch.dpatch Finished applying... $ autoreconf $ runhaskell Setup configure Setup.hs:3:0: Warning: In the use of `defaultUserHooks' (imported from Distribution.Simple): Deprecated: "Use simpleUserHooks or autoconfUserHooks, unless you need Cabal-1.2 compatibility in which case you must stick with defaultUserHooks" Warning: defaultUserHooks in Setup script is deprecated. Configuring network-2.2.1.5... configure: WARNING: unrecognized options: --with-hc checking build system type... i686-pc-cygwin checking host system type... i686-pc-cygwin checking for gcc... gcc checking for C compiler default output file name... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for an ANSI C-conforming const... yes checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking for stdlib.h... (cached) yes checking for sys/types.h... (cached) yes checking for unistd.h... (cached) yes checking winsock2.h usability... no checking winsock2.h presence... yes configure: WARNING: winsock2.h: present but cannot be compiled configure: WARNING: winsock2.h: check for missing prerequisite headers? configure: WARNING: winsock2.h: see the Autoconf documentation configure: WARNING: winsock2.h: section "Present But Cannot Be Compiled" configure: WARNING: winsock2.h: proceeding with the compiler's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to libraries@haskell.org ## configure: WARNING: ## ------------------------------------ ## checking for winsock2.h... no checking ws2tcpip.h usability... no checking ws2tcpip.h presence... yes configure: WARNING: ws2tcpip.h: present but cannot be compiled configure: WARNING: ws2tcpip.h: check for missing prerequisite headers? configure: WARNING: ws2tcpip.h: see the Autoconf documentation configure: WARNING: ws2tcpip.h: section "Present But Cannot Be Compiled" configure: WARNING: ws2tcpip.h: proceeding with the compiler's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to libraries@haskell.org ## configure: WARNING: ## ------------------------------------ ## checking for ws2tcpip.h... no checking wspiapi.h usability... no checking wspiapi.h presence... no checking for wspiapi.h... no checking arpa/inet.h usability... yes checking arpa/inet.h presence... yes checking for arpa/inet.h... yes checking netdb.h usability... yes checking netdb.h presence... yes checking for netdb.h... yes checking netinet/in.h usability... yes checking netinet/in.h presence... yes checking for netinet/in.h... yes checking netinet/tcp.h usability... yes checking netinet/tcp.h presence... yes checking for netinet/tcp.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking sys/uio.h usability... yes checking sys/uio.h presence... yes checking for sys/uio.h... yes checking sys/un.h usability... yes checking sys/un.h presence... yes checking for sys/un.h... yes checking for readlink... yes checking for symlink... yes checking for struct msghdr.msg_control... yes checking for struct msghdr.msg_accrights... no checking for struct sockaddr.sa_len... no checking for in_addr_t in netinet/in.h... yes checking for SO_PEERCRED and struct ucred in sys/socket.h... yes checking for _head_libws2_32_a in -lws2_32... yes checking for getaddrinfo... no checking for getaddrinfo if WINVER is 0x0501... no checking for gai_strerror... no checking whether AI_ADDRCONFIG is declared... no checking whether AI_ALL is declared... no checking whether AI_NUMERICSERV is declared... no checking whether AI_V4MAPPED is declared... no checking for sendfile in sys/sendfile.h... no checking for sendfile in sys/socket.h... no checking for gethostent... no configure: creating ./config.status config.status: creating network.buildinfo config.status: creating include/HsNetworkConfig.h configure: WARNING: unrecognized options: --with-hc Setup: Missing dependency on a foreign library: * Missing header file: HsNet.h This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. $ runhaskell Setup build Setup.hs:3:0: Warning: In the use of `defaultUserHooks' (imported from Distribution.Simple): Deprecated: "Use simpleUserHooks or autoconfUserHooks, unless you need Cabal-1.2 compatibility in which case you must stick with defaultUserHooks" Preprocessing library network-2.2.1.5... In file included from Network\BSD.hsc:17: include/HsNet.h:78:22: sys/uio.h: No such file or directory include/HsNet.h:81:25: sys/socket.h: No such file or directory include/HsNet.h:84:26: netinet/tcp.h: No such file or directory include/HsNet.h:87:25: netinet/in.h: No such file or directory include/HsNet.h:90:21: sys/un.h: No such file or directory include/HsNet.h:93:24: arpa/inet.h: No such file or directory include/HsNet.h:96:19: netdb.h: No such file or directory In file included from Network\BSD.hsc:17: include/HsNet.h:138: error: syntax error before "addr" include/HsNet.h: In function `my_inet_ntoa': include/HsNet.h:146: error: storage size of 'a' isn't known include/HsNet.h:147: error: `addr' undeclared (first use in this function) include/HsNet.h:147: error: (Each undeclared identifier is reported only once include/HsNet.h:147: error: for each function it appears in.) include/HsNet.h:148: warning: return makes pointer from integer without a cast Network\BSD.hsc: In function `main': Network\BSD.hsc:149: error: invalid application of `sizeof' to incomplete type `servent' Network\BSD.hsc:149: error: invalid application of `sizeof' to incomplete type `servent' Network\BSD.hsc:149: error: invalid application of `sizeof' to incomplete type `servent' Network\BSD.hsc:153: error: dereferencing pointer to incomplete type Network\BSD.hsc:154: error: dereferencing pointer to incomplete type Network\BSD.hsc:157: error: dereferencing pointer to incomplete type Network\BSD.hsc:158: error: dereferencing pointer to incomplete type Network\BSD.hsc:253: error: invalid application of `sizeof' to incomplete type `protoent' Network\BSD.hsc:253: error: invalid application of `sizeof' to incomplete type `protoent' Network\BSD.hsc:253: error: invalid application of `sizeof' to incomplete type `protoent' Network\BSD.hsc:257: error: dereferencing pointer to incomplete type Network\BSD.hsc:258: error: dereferencing pointer to incomplete type Network\BSD.hsc:265: error: dereferencing pointer to incomplete type Network\BSD.hsc:343: error: invalid application of `sizeof' to incomplete type `hostent' Network\BSD.hsc:343: error: invalid application of `sizeof' to incomplete type `hostent' Network\BSD.hsc:343: error: invalid application of `sizeof' to incomplete type `hostent' Network\BSD.hsc:347: error: dereferencing pointer to incomplete type Network\BSD.hsc:348: error: dereferencing pointer to incomplete type Network\BSD.hsc:351: error: dereferencing pointer to incomplete type Network\BSD.hsc:353: error: dereferencing pointer to incomplete type Network\BSD.hsc:452: error: invalid application of `sizeof' to incomplete type `hostent' Network\BSD.hsc:452: error: invalid application of `sizeof' to incomplete type `hostent' Network\BSD.hsc:452: error: invalid application of `sizeof' to incomplete type `hostent' Network\BSD.hsc:456: error: dereferencing pointer to incomplete type Network\BSD.hsc:457: error: dereferencing pointer to incomplete type Network\BSD.hsc:460: error: dereferencing pointer to incomplete type Network\BSD.hsc:461: error: dereferencing pointer to incomplete type compiling dist\build\Network\BSD_hsc_make.c failed command was: C:\ghc\ghc-6.12.1-rc2\mingw\bin\gcc.exe -c -D__GLASGOW_HASKELL__=612 -Iinclude -DCALLCONV=ccall -DBASE4 -IC:\ghc\ghc-6.12.1-rc2\base-4.2.0.0\include -IC:\ghc\ghc-6.12.1-rc2/include -IC:\ghc\ghc-6.12.1-rc2/include -IC:/ghc/ghc-6.12.1-rc2/lib/include/ dist\build\Network\BSD_hsc_make.c -o dist\build\Network\BSD_hsc_make.o From garious at gmail.com Wed Nov 25 00:35:13 2009 From: garious at gmail.com (Greg Fitzgerald) Date: Wed Nov 25 00:10:39 2009 Subject: Bug in Parsec.Token Message-ID: <1f3dc80d0911242135k69177f02o1377b24a91b30f2c@mail.gmail.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: parsec-2.1.0.1.patch Type: application/octet-stream Size: 793 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20091125/5a49f3a6/parsec-2.1.0.1.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: parsec-3.0.1.patch Type: application/octet-stream Size: 680 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20091125/5a49f3a6/parsec-3.0.1.obj From qdunkan at gmail.com Wed Nov 25 01:33:55 2009 From: qdunkan at gmail.com (Evan Laforge) Date: Wed Nov 25 01:09:03 2009 Subject: export toDescList from Data.Map In-Reply-To: <4B0BBCB9.8050506@gmail.com> References: <2518b95d0809081546y42f85696h694c1003e82dc5de@mail.gmail.com> <2518b95d0910112038u11e883b2ka61188b78aab0d18@mail.gmail.com> <4B0BBCB9.8050506@gmail.com> Message-ID: <2518b95d0911242233le9253c9i5d55caf0c67dbbed@mail.gmail.com> > Yes, 6.12.1 includes that patch. Excellent. It's small but it makes me happy :) From duncan.coutts at googlemail.com Wed Nov 25 05:16:40 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Wed Nov 25 04:51:49 2009 Subject: Cabal and Hsc2hs Build Phase Options In-Reply-To: <20091120144419.GA20012@neptune.mattcox.ca> References: <20091120071903.GA9057@neptune.mattcox.ca> <1258711210.4896.25599.camel@localhost> <20091120144419.GA20012@neptune.mattcox.ca> Message-ID: <1259144200.4896.55631.camel@localhost> On Fri, 2009-11-20 at 09:44 -0500, Matthew William Cox wrote: > On Fri, Nov 20, 2009 at 10:00:10AM +0000, Duncan Coutts wrote: > > The builder is in a position to know if special flags are needed. Also, > > since the builder controls the build environment they could use special > > flags anyway by changing the $PATH and using wrapper scripts, so there's > > no point in not letting the builder do what they want. > > The author is also in a position to know that the same flags need to be > used in two different build phases. In this case, I'm using > autoconfUserHooks to find out how to use the system's MPI library. A > builder should direct the autoconf script to the correct library (if there > are multiple) using an environment variable. In either case, autoconf > hands me a compiler wrapper which needs to be used to compile and link all C > code (and the FFI using code). There's no other portable way to use MPI, > like pkgconfig or whathaveyou to suss out the magic CFLAGS and LDFLAGS > needed. Wow, that's fairly horrible. I wonder what the MPI people were thinking. You can't have two dependencies that use this trick since they would fight over which cc to use. Does it let you tell it which gcc to wrap or does it try and pick the gcc itself? > Anyways, from my perspective as an author that wants to provide the > simplist building experience for someone else, I'd rather be able to > tell them in the docs to run > runhaskell Setup.hs configure && runhaskell Setup.hs build > rather than to 1) runhaskell Setup.hs configure, 2) read the generated > buildinfo script to determine the compiler and linker passed to ghc, 3) > call runhaskell Setup.hs build --hsc2hs-options="-cc=$COMPILER > --ld=$COMPILER" where $COMPILER is the exact compiler wrapper used by > Ghc, and failing to do this may result in failure or having a > schizophrenic build compiled against one library and linked against > another. Right, so you'll need a custom Setup.hs. It will collect the info from your ./configure script. It will need to update the ProgramConfiguration environment that Cabal uses. The ProgramConfiguration tells Cabal where various named programs live and if they need any extra flags (this is the information store that the --with-prog= and --prog-options= flags modify). You'll want to set the gcc to be used. That will propagate automatically to the hsc2hs call, though not to ghc (though arguably it should). You'll need to modify the program configuration to add in the appropriate flags to the ghc calls. > The user arguments at the command line should always override the ones > in a configuration file of course. That gets you the best of both > worlds. I'm not quite sure how that should work. The initial ProgramConfiguration you get will contain the info from the user command line. Can you tell the MPI thing which gcc it should wrap? If so then you can respect the user arguments, otherwise I don't really see how you can and also make it work. > tl;dr: you can have your cake and eat it too if the user's command line > arguments always override the equivalent configuration file directive. > > > Now I take it that you really want to use your mpicc just for hsc2hs and > > not for all cases where cabal (or programs that cabal calls) call gcc > > right? I ask because we've got another open feature request ticket that > > asks that cabal --with-gcc=blah should pass that gcc on to ghc, hsc2hs, > > etc etc. > > I need it for all phases of the build (GHC, hsc2hs, etc.) Right now, > it's override GHC using ghc-options: -pgmc ... -pgml ... but it would be > even better if there was one central way. We've not quite decided if cabal blah --with-gcc= should set just the gcc that cabal calls directly, or if cabal should also instruct all programs that call gcc to use that same one. What makes me most nervous is that ghc has a fairly intimate relationship with gcc and especially when it comes to gcc flags, not all gcc flags are compatible with ghc. > Again, a --with-linker would be nice to add, and especially, a > configuration file directive to set it statically based on an autoconf > check with the option to be overridden by a user's command line > arguments. Would it be enough to have a central setting for which gcc to use, as mentioned above? > > BTW, as a short-term workaround you can always use the wrapper script > > trick: --with-hsc2hs=hsc2hs.sh > > I take it there's no way of doing this statically? Not in the .cabal file. You can do what you like in the Setup.hs though. Duncan From p.k.f.holzenspies at utwente.nl Wed Nov 25 06:56:01 2009 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?ISO-8859-1?Q?H=F6lzenspies?=) Date: Wed Nov 25 06:31:10 2009 Subject: Roundup on proposal 3671 [was: Re: Proposal (Trac ticket #3671): Add takeRec, genericTakeRec and spanRec to Data.List] In-Reply-To: <4B0BA624.6010202@dfki.de> References: <1258465664.2704.6.camel@ewi1043> <20091117143517.GA443@matrix.chaos.earth.li> <2608b8a80911181442k1525eb1r1fc5b2ef32d7ecc5@mail.gmail.com> <884298590.20091119062849@gmail.com> <1258627651.7681.62.camel@ewi1043> <2608b8a80911190328g3a43ad2eoedbdded5bf1f349@mail.gmail.com> <1258639332.7681.75.camel@ewi1043> <1258639816.7681.80.camel@ewi1043> <4B06D5A5.9080309@dfki.de> <4B0A780C.5070300@jellybean.co.uk> <4B0BA624.6010202@dfki.de> Message-ID: <1259150161.13426.31.camel@ewi1043> Dear Christian, et al. Thanks for the summary, Christian. I've given some detailed comments below, but I'll give the gist here. The ticket has indeed moved on quite a bit. Some more expressive functions were proposed that weren't part of the ticket, but that maybe should have been. Some of the originally proposed functions can be expressed easily in these more expressive ones and, therefore, may not be wanted inclusions any more. I suggest we get everyone to +1 or -1 on the following list of possible new inclusions (where the slash-separated list of names all represent the same function - for +1s also indicate name preference): - takeRec / splitAts / groupsOf / segmentsOf :: Int -> [a] -> [[a]] - genericTakeRec / genericSplitAts / genericGroupsOf / genericSegmentsOf :: Integral i => i -> [a] -> [[a]] - spanRec / spans :: (a -> Bool) -> [a] -> [[a]] - breakRec / breaks :: (a -> Bool) -> [a] -> [[a]] - runs :: (a -> a -> Bool) -> [a] -> [[a]] - run :: (a -> a -> Bool) -> [a] -> ([a],[a]) - replace :: Eq a => [a] -> [a] -> [a] -> [a] - replaceBy :: ([a] -> (b, [a])) -> [a] -> [b] The implementations of the chosen functions should, in my mind, be based on profiling results. As an open procedural question: can a proposal track ticket be obsolidated by a new ticket? What is the common procedure for revising a proposal? Regards, Philip On Tue, 2009-11-24 at 10:23 +0100, Christian Maeder wrote: > Ok, lets try to get back to the proposal. Good idea. I think there is general consensus that *something* along these lines should be added, but we have to agree on what. Clearly, the original proposal has undergone such revision that we might want to obsolidate it. Is there a replacement procedure for Trac proposals? > 1. We want something like takeRec being named splitAts or groupsOf > (groupsOf is too similar to the existing groupsBy) Although I liked groupsOf, I see your point. Suggestion for alternative: segmentsOf > 2. genericTakeRec is just a variant of takeRec based on genericSplitAt > rather than splitAt (or genericTake, genericDrop instead of take, drop) Correct, but whatever it's going to be called, a genericX variant seems reasonable. > 3. spanRec changed to a mutual recursive implementation for spans and > breaks (in the ticket) that is not supported much. Rather breaks was > more discussed in this thread as a splitting function (that was > discussed years before under splitBy or splitOn without any agreement.) > > Agreement seems to be about "breaks p = spans (not . p)" (or vice versa) > > Furthermore, proposal for runs (4.) and replace (5.) came up in this > thread, that are not part of the ticket. You're absolutely right about this and I feel it would be better to fix this. Hence: Is there a replacement procedure for a proposal ticket? > 4. I find "runs" useful in the sense proposed by Philip with type > > runs :: (a -> a -> Bool) -> [a] -> [[a]] > > > runs (<) [1,2,3,4,3,4,5] > [[1,2,3,4],[3,4,5]] > > (there's no proposal to rename groupsBy) > > 5. The type of my replace function was: > > replace :: Eq a => [a] -> a -> [a] -> [a] > > and a (reasonable) alternative would be to replace a sublist by another > sublist and not by a single element. I actually thought your replaceBy was very nice, especially because it allows for the expression of all the other functions. Most significantly, the '[b]' result type really works for me. > Which of the above functions (1. - 4.) should be part of the proposal? Methinks 1-5, no? > How should these functions be implemented? > > I only made a proposal how they could be implemented using replaceBy > (below), but direct recursive definitions may be more appropriate. > > I.e. unlines and unwords are also defined with explicit recursion > although alternative definitions are there (based on concatMap and foldr1) I think implementation choices should depend more than anything on performance. As I remarked somewhere else in this thread, performance might very well be a sliding argument over different compiler versions. I would propose we first vote on the functions we want in there (it seems that also determines some of the implementation choices available) and then to just profile the alternative implementations. From Christian.Maeder at dfki.de Wed Nov 25 11:45:16 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Nov 25 11:20:20 2009 Subject: Roundup on proposal 3671 [was: Re: Proposal (Trac ticket #3671): Add takeRec, genericTakeRec and spanRec to Data.List] In-Reply-To: <1259150161.13426.31.camel@ewi1043> References: <1258465664.2704.6.camel@ewi1043> <20091117143517.GA443@matrix.chaos.earth.li> <2608b8a80911181442k1525eb1r1fc5b2ef32d7ecc5@mail.gmail.com> <884298590.20091119062849@gmail.com> <1258627651.7681.62.camel@ewi1043> <2608b8a80911190328g3a43ad2eoedbdded5bf1f349@mail.gmail.com> <1258639332.7681.75.camel@ewi1043> <1258639816.7681.80.camel@ewi1043> <4B06D5A5.9080309@dfki.de> <4B0A780C.5070300@jellybean.co.uk> <4B0BA624.6010202@dfki.de> <1259150161.13426.31.camel@ewi1043> Message-ID: <4B0D5F1C.4010601@dfki.de> Philip K.F. H?lzenspies schrieb: > Dear Christian, et al. > > Thanks for the summary, Christian. I've given some detailed comments > below, but I'll give the gist here. > > The ticket has indeed moved on quite a bit. Some more expressive > functions were proposed that weren't part of the ticket, but that maybe > should have been. Some of the originally proposed functions can be > expressed easily in these more expressive ones and, therefore, may not > be wanted inclusions any more. > > I suggest we get everyone to +1 or -1 on the following list of possible > new inclusions (where the slash-separated list of names all represent > the same function - for +1s also indicate name preference): > > - takeRec / splitAts / groupsOf / segmentsOf :: Int -> [a] -> [[a]] +1 in http://hackage.haskell.org/package/split such a function is called "chunk" and "splitEvery". My preference would be "chunks", but "splitAts", "splits", or "segmentsOf" is fine, too. > - genericTakeRec / genericSplitAts / genericGroupsOf / > genericSegmentsOf :: Integral i => i -> [a] -> [[a]] +1 How should the above functions behave for the corner case of the number being less than 1? I see several options: 1. abort (my preference) 2. return the empty list 3. return the singleton list of the input (non-intuitive) 4. return the infinite list of empty lists > - spanRec / spans :: (a -> Bool) -> [a] -> [[a]] > - breakRec / breaks :: (a -> Bool) -> [a] -> [[a]] +1 in http://hackage.haskell.org/package/split there is a function called splitWhen. The main point to clarify is how delimiters (determined by the input predicate for breaks) influence the output list. 1. Should delimiters be part of the output? 2. Should consecutive delimiters produce separate sublists 3. Should empty lists be elements of the result list 4. If yes, should leading or trailing delimiters produce leading or trailing empty list elements. > - runs :: (a -> a -> Bool) -> [a] -> [[a]] +1 maybe under a different name: "runBy" > - run :: (a -> a -> Bool) -> [a] -> ([a],[a]) -1 "runs" is similar to "groupBy", therefore I proposed "runBy" for "runs". For groupBy we have no function that's splits off the first group only, therefore (I think) we don't need one for the first run, too. Furthermore, the relation between "runBy" und "run" would be different from the one between "groupBy" and "group". An alternative would be to use "firstRunBy" for "run" and also add a function "firstGroupBy". > - replace :: Eq a => [a] -> [a] -> [a] -> [a] +1 Here also the corner case needs to be clarified, what should happen, if the empty list should be replaced. > - replaceBy :: ([a] -> (b, [a])) -> [a] -> [b] -1 As a recursion scheme that is comparable to iterate or replicate the name is too special. I also just notice that a more general recursion scheme would be: recurse :: (a -> (b, Maybe a)) -> a -> [b] or the given unfoldr :: (b -> Maybe (a, b)) -> b -> [a] unfoldr could be used directly in a similar way than my replaceBy. In fact: replaceBy splt = unfoldr (\ l -> if null l then Nothing else Just (splt l)) So replaceBy is not really needed! > The implementations of the chosen functions should, in my mind, be based > on profiling results. Yes. > As an open procedural question: can a proposal track ticket be > obsolidated by a new ticket? What is the common procedure for revising a > proposal? I actually don't know. But I would recommend to close this ticket and open a new one (or several new ones) if some agreement is achieved (or none without agreement). Cheers Christian From matt at mattcox.ca Wed Nov 25 12:25:48 2009 From: matt at mattcox.ca (Matthew William Cox) Date: Wed Nov 25 12:00:51 2009 Subject: Cabal and Hsc2hs Build Phase Options In-Reply-To: <1259144200.4896.55631.camel@localhost> References: <20091120071903.GA9057@neptune.mattcox.ca> <1258711210.4896.25599.camel@localhost> <20091120144419.GA20012@neptune.mattcox.ca> <1259144200.4896.55631.camel@localhost> Message-ID: <20091125172548.GA4416@neptune.mattcox.ca> On Wed, Nov 25, 2009 at 10:16:40AM +0000, Duncan Coutts wrote: > Right, so you'll need a custom Setup.hs. It will collect the info from > your ./configure script. It will need to update the ProgramConfiguration > environment that Cabal uses. The ProgramConfiguration tells Cabal where > various named programs live and if they need any extra flags (this is > the information store that the --with-prog= and --prog-options= flags > modify). > > You'll want to set the gcc to be used. That will propagate automatically > to the hsc2hs call, though not to ghc (though arguably it should). > You'll need to modify the program configuration to add in the > appropriate flags to the ghc calls. Thanks for sketching this out. It seems like exactly what I need. Regards, Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20091125/b3cd2931/attachment.bin From mietek at gmail.com Thu Nov 26 07:41:26 2009 From: mietek at gmail.com (=?UTF-8?Q?Mietek_B=C4=85k?=) Date: Thu Nov 26 07:16:47 2009 Subject: Guarantees regarding finalizers In-Reply-To: <13dd2de20911260435q29619d0av4b12661dd8931478@mail.gmail.com> References: <13dd2de20911260435q29619d0av4b12661dd8931478@mail.gmail.com> Message-ID: <13dd2de20911260441x7751680cwae75f7fee00fe8d6@mail.gmail.com> Hello, I'm writing a binding to a C library, which requires an explicit cleanup call before program termination. While looking for a way to automatize this, I noticed a discrepancy in the standard library documentation. The Foreign.Concurrent documentation states: "The only guarantee is that the finalizer runs before the program terminates." (http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign-Concurrent.html) On the other hand, the Foreign.ForeignPtr documentation states: "Indeed, there is no guarantee that the finalizer is executed at all; a program may exit with finalizers outstanding." (http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign-ForeignPtr.html) Note that Foreign.Concurrent.newForeignPtr is implemented in GHC as GHC.ForeignPtr.newConcForeignPtr. The newConcForeignPtr comments also state: "There is no guarantee of promptness, and in fact there is no guarantee that the finalizer will eventually run at all." (http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-ForeignPtr.html) As much as I would like the Foreign.Concurrent guarantee to be true, this seems to me like a documentation bug. Best regards, -- Mietek B?k From mle+hs at mega-nerd.com Thu Nov 26 16:16:50 2009 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Thu Nov 26 15:52:08 2009 Subject: MTL vs Transformers. Any status update? Message-ID: <20091127081650.fd48e441.mle+hs@mega-nerd.com> HI all, Has any progress been made on this? There are a couple of things I would like to package for Debian (also use myself of cource) and they can't progress until the current mess of mtl vs transformers has been sorted out. Is there anything I can do to progress this? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From ross at soi.city.ac.uk Thu Nov 26 19:33:02 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Nov 26 19:08:24 2009 Subject: MTL vs Transformers. Any status update? In-Reply-To: <20091127081650.fd48e441.mle+hs@mega-nerd.com> References: <20091127081650.fd48e441.mle+hs@mega-nerd.com> Message-ID: <20091127003302.GA29911@soi.city.ac.uk> As I understand it, the Haskell Platform timetable means this will take some time. I think the ultimate aim should be that everyone moves to transformers and monads-fd (probably with some renaming of modules in the latter), and mtl disappears. If we decide on that, this is we could get there: 1. rename the modules in monads-fd to their final names. (We also need suggestions for what those names should be.) 2. release mtl-2.0 as a deprecated compatibility layer over transformers and monads-fd, and get all users to hide all versions of mtl, including the new one. 19 packages on hackage must be updated to work with the new version. 3. encourage authors to upgrade their packages to depend on transformers and (possibly) monads-fd in place of mtl. 4. after a couple of cycles, remove mtl from the platform. From nicolas.pouillard at gmail.com Sat Nov 28 09:04:40 2009 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Sat Nov 28 08:39:47 2009 Subject: [Haskell-cafe] ANNOUNCE: deepseq-1.0.0.0 In-Reply-To: <4B03B680.3060108@gmail.com> References: <4B028245.1080201@gmail.com> <1258460604-sup-9104@peray> <4B03B680.3060108@gmail.com> Message-ID: <1259417027-sup-1533@peray> Excerpts from Simon Marlow's message of Wed Nov 18 09:55:28 +0100 2009: > On 17/11/2009 12:25, Nicolas Pouillard wrote: > > Excerpts from Simon Marlow's message of Tue Nov 17 12:00:21 +0100 2009: > >> I've just uploaded deepseq-1.0.0.0 to Hackage > > > > Great! > > > > I'm wondering what is the need/purpose for DeepSeqIntegral and DeepSeqOrd? > > I don't actually know, they were previously NFDataIntegral and NFDataOrd > respectively. Unless anyone can think of a reason to want these, I'll > remove them. No one claimed for them, I think and are just useless, and thus confusing. Best regards, -- Nicolas Pouillard http://nicolaspouillard.fr From duncan.coutts at googlemail.com Sat Nov 28 11:28:56 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Sat Nov 28 11:03:57 2009 Subject: Advance warning to package authors of breakage In-Reply-To: <1258332463.4896.1545.camel@localhost> References: <1258332463.4896.1545.camel@localhost> Message-ID: <1259425736.4896.74792.camel@localhost> On Mon, 2009-11-16 at 00:47 +0000, Duncan Coutts wrote: > package authors, > > I'm preparing to release two new versions of cabal-install. The cabal-install 0.6.4 version has now been released. Users will get prompted to upgrade when they next run cabal update. Note this version still will not work with ghc-6.12. But it will give people a better error message and tell them how to upgrade. The (as yet unreleased) cabal-install 0.8.x version will work with ghc-6.12. This version is only available via darcs at the moment. darcs get --partial http://darcs.haskell.org/cabal-install If you do want to test the ghc-6.12 RC, I recommend upgrading your cabal-install to a 0.8.x version before removing any older ghc version you've currently got. One additional fallout from the cabal-install release is that mtlx-0.1.1 is now broken. The cabal program will refuse to unpack mtlx-0.1.1.tar.gz because it classifies it as a tarbomb. A tarbomb is a tar file that would unpack files into the top level directory rather than all files under the subdirectory ./mtlx-0.1.1/. The tar file contains the stray entry "./._mtlx-0.1.1". This package will need to be re-uploaded. My suggestion is to use cabal sdist since this only selects the required files (but do check all the required files are listed) and it always uses a portable tar format. Duncan From duncan.coutts at googlemail.com Sat Nov 28 11:37:28 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Sat Nov 28 11:12:24 2009 Subject: Advance warning to package authors of breakage with Cabal-1.8 Message-ID: <1259426248.4896.74838.camel@localhost> package authors, I'm preparing to release a new version of Cabal. This is the one that will come with ghc-6.12. A few packages with custom Setup.hs scripts will require some changes to compile with Cabal version 1.8. In most cases it is possible to have them continue to work with version 1.6 too. When you test your changes, please test against the darcs version of Cabal-1.8 rather than the one included in 6.12 RC2. The reason is that I've added in a couple API backwards compat fixes, so there's actually less to fix than you would find with the RC2 (and for at least one of those if you fix it to work with the Cabal pre-release version included in 6.12 RC2 it'll be impossible to make it work with Cabal-1.6 too). darcs get --partial http://darcs.haskell.org/cabal-branches/cabal-1.8 These minor changes will of course be rolled into the final version that comes with ghc 6.12.1. * HDBC-postgresql, MissingPy, Omega, HDBC-mysql These use the function requireProgram in their Setup.hs. This function drops one parameter in Cabal-1.8. To make the Setup.hs continue to work with Cabal-1.6 too, I suggest changing code like this: (pgconfigProg, _) <- requireProgram verbosity pgconfigProgram AnyVersion (withPrograms lbi) let pgconfig = rawSystemProgramStdout verbosity pgconfigProg into just: let pgconfig = rawSystemProgramStdoutConf verbosity pgconfigProgram (withPrograms lbi) * haskeline This uses GHC.build in its Setup.hs which no longer exists. It got split into GHC.buildLib and buildExe. Duncan From duncan.coutts at googlemail.com Sat Nov 28 11:40:49 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Sat Nov 28 11:15:44 2009 Subject: MTL vs Transformers. Any status update? In-Reply-To: <20091127003302.GA29911@soi.city.ac.uk> References: <20091127081650.fd48e441.mle+hs@mega-nerd.com> <20091127003302.GA29911@soi.city.ac.uk> Message-ID: <1259426449.4896.74853.camel@localhost> On Fri, 2009-11-27 at 00:33 +0000, Ross Paterson wrote: > As I understand it, the Haskell Platform timetable means this will > take some time. > > I think the ultimate aim should be that everyone moves to transformers > and monads-fd (probably with some renaming of modules in the latter), > and mtl disappears. If we decide on that, this is we could get there: > > 1. rename the modules in monads-fd to their final names. > (We also need suggestions for what those names should be.) > 2. release mtl-2.0 as a deprecated compatibility layer over transformers > and monads-fd, and get all users to hide all versions of mtl, including > the new one. 19 packages on hackage must be updated to work with > the new version. > 3. encourage authors to upgrade their packages to depend on transformers > and (possibly) monads-fd in place of mtl. > 4. after a couple of cycles, remove mtl from the platform. Could someone remind me why it's better for use to ask everyone to switch to monads-fd / transformers rather than to mtl-2? Does that make the transition easier? If it makes little difference I'd suggest making mtl-2 the new recommendation (with whatever content you've all agreed) simply because it's easier to explain to everyone else. Duncan From ross at soi.city.ac.uk Sat Nov 28 11:56:50 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sat Nov 28 11:32:14 2009 Subject: MTL vs Transformers. Any status update? In-Reply-To: <1259426449.4896.74853.camel@localhost> References: <20091127081650.fd48e441.mle+hs@mega-nerd.com> <20091127003302.GA29911@soi.city.ac.uk> <1259426449.4896.74853.camel@localhost> Message-ID: <20091128165650.GA15637@soi.city.ac.uk> On Sat, Nov 28, 2009 at 04:40:49PM +0000, Duncan Coutts wrote: > Could someone remind me why it's better for use to ask everyone to > switch to monads-fd / transformers rather than to mtl-2? Does that make > the transition easier? The problem is that transformers and mtl use the same module names, such as Control.Monad.Identity. Unless one of these packages is hidden, people using ghci or ghc --make will have problems. From marlowsd at gmail.com Sat Nov 28 12:21:36 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Sat Nov 28 11:56:49 2009 Subject: [Haskell-cafe] ANNOUNCE: deepseq-1.0.0.0 In-Reply-To: <1259417027-sup-1533@peray> References: <4B028245.1080201@gmail.com> <1258460604-sup-9104@peray> <4B03B680.3060108@gmail.com> <1259417027-sup-1533@peray> Message-ID: <4B115C20.6040805@gmail.com> On 28/11/09 14:04, Nicolas Pouillard wrote: > Excerpts from Simon Marlow's message of Wed Nov 18 09:55:28 +0100 2009: >> On 17/11/2009 12:25, Nicolas Pouillard wrote: >>> Excerpts from Simon Marlow's message of Tue Nov 17 12:00:21 +0100 2009: >>>> I've just uploaded deepseq-1.0.0.0 to Hackage >>> >>> Great! >>> >>> I'm wondering what is the need/purpose for DeepSeqIntegral and DeepSeqOrd? >> >> I don't actually know, they were previously NFDataIntegral and NFDataOrd >> respectively. Unless anyone can think of a reason to want these, I'll >> remove them. > > No one claimed for them, I think and are just useless, and thus confusing. Already gone in deepseq-1.1.0.0, which also renamed DeepSeq back to NFData. Cheers, Simon From aslatter at gmail.com Sat Nov 28 16:01:26 2009 From: aslatter at gmail.com (Antoine Latter) Date: Sat Nov 28 15:36:21 2009 Subject: GHC 6.12 + zlib + Mac OS 10.6 Message-ID: <694519c50911281301j51fa67bv88aee368d93f92dd@mail.gmail.com> Hello folks, Everything has been going beautifully with the latest versions of GHC 6.12, except that anything involving zlib dies at run-time. In ghci: > :m Codec.Compression.Zlib > :m +Data.ByteString.Lazy.Char8 > :s -XOverloadedStrings > compress "hello" *** Exception: user error (Codec.Compression.Zlib: incompatible zlib version) I'm running OS X 10.6 on a 64-bit machine. I've heard of folks running into this with GHC 6.10 on OS X 10.6, who got rid of it by removing mac-ports. I tried that and it didn't change anything. My mac-ports install should have all been universal binaries anyway. I imagine I'm somehow building against a 64-bit version of the zlib library, but I'm not sure at what step I'm supposed to do things different, or what precisely I'm supposed to do different. Thanks, Antoine From thomas.dubuisson at gmail.com Sat Nov 28 16:11:46 2009 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Sat Nov 28 15:46:39 2009 Subject: MTL vs Transformers. Any status update? In-Reply-To: <20091128165650.GA15637@soi.city.ac.uk> References: <20091127081650.fd48e441.mle+hs@mega-nerd.com> <20091127003302.GA29911@soi.city.ac.uk> <1259426449.4896.74853.camel@localhost> <20091128165650.GA15637@soi.city.ac.uk> Message-ID: <4c44d90b0911281311j682c3813n69c26578106af484@mail.gmail.com> On Sat, Nov 28, 2009 at 8:56 AM, Ross Paterson wrote: > On Sat, Nov 28, 2009 at 04:40:49PM +0000, Duncan Coutts wrote: >> Could someone remind me why it's better for use to ask everyone to >> switch to monads-fd / transformers rather than to mtl-2? Does that make >> the transition easier? > > The problem is that transformers and mtl use the same module names, > such as Control.Monad.Identity. ?Unless one of these packages is hidden, > people using ghci or ghc --make will have problems. I've happily used LANGUAGE PackageImports to handle transformer / mtl conflicts. I don't see why either one must change their module names and there are obvious disadvantages. Thomas From ganesh at earth.li Sat Nov 28 16:14:51 2009 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sat Nov 28 15:49:43 2009 Subject: MTL vs Transformers. Any status update? In-Reply-To: <4c44d90b0911281311j682c3813n69c26578106af484@mail.gmail.com> References: <20091127081650.fd48e441.mle+hs@mega-nerd.com> <20091127003302.GA29911@soi.city.ac.uk> <1259426449.4896.74853.camel@localhost> <20091128165650.GA15637@soi.city.ac.uk> <4c44d90b0911281311j682c3813n69c26578106af484@mail.gmail.com> Message-ID: On Sat, 28 Nov 2009, Thomas DuBuisson wrote: > On Sat, Nov 28, 2009 at 8:56 AM, Ross Paterson wrote: >> On Sat, Nov 28, 2009 at 04:40:49PM +0000, Duncan Coutts wrote: >>> Could someone remind me why it's better for use to ask everyone to >>> switch to monads-fd / transformers rather than to mtl-2? Does that make >>> the transition easier? >> >> The problem is that transformers and mtl use the same module names, >> such as Control.Monad.Identity. ?Unless one of these packages is hidden, >> people using ghci or ghc --make will have problems. > > I've happily used LANGUAGE PackageImports to handle transformer / mtl > conflicts. I don't see why either one must change their module names > and there are obvious disadvantages. Is there long-term value in having both packages, if mtl ends up as just re-exporting pieces of transformers+monads-fd? I guess it reduces the dependencies people have to declare, but that seems marginal to me. Ganesh From lemming at henning-thielemann.de Sat Nov 28 16:17:06 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Nov 28 15:52:31 2009 Subject: MTL vs Transformers. Any status update? In-Reply-To: <4c44d90b0911281311j682c3813n69c26578106af484@mail.gmail.com> References: <20091127081650.fd48e441.mle+hs@mega-nerd.com> <20091127003302.GA29911@soi.city.ac.uk> <1259426449.4896.74853.camel@localhost> <20091128165650.GA15637@soi.city.ac.uk> <4c44d90b0911281311j682c3813n69c26578106af484@mail.gmail.com> Message-ID: On Sat, 28 Nov 2009, Thomas DuBuisson wrote: > On Sat, Nov 28, 2009 at 8:56 AM, Ross Paterson wrote: >> >> The problem is that transformers and mtl use the same module names, >> such as Control.Monad.Identity. ?Unless one of these packages is hidden, >> people using ghci or ghc --make will have problems. > > I've happily used LANGUAGE PackageImports to handle transformer / mtl > conflicts. I don't see why either one must change their module names > and there are obvious disadvantages. This PRAGMA is only available in GHC, is it? From nonowarn at gmail.com Sat Nov 28 16:54:42 2009 From: nonowarn at gmail.com (Yusaku Hashimoto) Date: Sat Nov 28 16:29:37 2009 Subject: GHC 6.12 + zlib + Mac OS 10.6 In-Reply-To: <694519c50911281301j51fa67bv88aee368d93f92dd@mail.gmail.com> References: <694519c50911281301j51fa67bv88aee368d93f92dd@mail.gmail.com> Message-ID: I think you installed zlib without proper flags to link with 32-bit libraries. configuring with ./Setup configure --with-hsc2hs='--cc-flag=-m32 --ld-flag=-m32' should do the tricks. See also http://hackage.haskell.org/trac/ghc/ticket/3681. HTH -~nwn On Sun, Nov 29, 2009 at 6:01 AM, Antoine Latter wrote: > Hello folks, > > Everything has been going beautifully with the latest versions of GHC > 6.12, except that anything involving zlib dies at run-time. In ghci: > >> :m Codec.Compression.Zlib >> :m +Data.ByteString.Lazy.Char8 >> :s -XOverloadedStrings >> compress "hello" > > *** Exception: user error (Codec.Compression.Zlib: incompatible zlib version) > > I'm running OS X 10.6 on a 64-bit machine. > > I've heard of folks running into this with GHC 6.10 on OS X 10.6, who > got rid of it by removing mac-ports. I tried that and it didn't change > anything. My mac-ports install should have all been universal binaries > anyway. > > I imagine I'm somehow building against a 64-bit version of the zlib > library, but I'm not sure at what step I'm supposed to do things > different, or what precisely I'm supposed to do different. > > Thanks, > Antoine > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From aslatter at gmail.com Sat Nov 28 18:00:57 2009 From: aslatter at gmail.com (Antoine Latter) Date: Sat Nov 28 17:35:52 2009 Subject: GHC 6.12 + zlib + Mac OS 10.6 In-Reply-To: References: <694519c50911281301j51fa67bv88aee368d93f92dd@mail.gmail.com> Message-ID: <694519c50911281500n17032304u310308fd2f404c1@mail.gmail.com> On Sat, Nov 28, 2009 at 3:54 PM, Yusaku Hashimoto wrote: > I think you installed zlib without proper flags to link with 32-bit > libraries. configuring with ./Setup configure > --with-hsc2hs='--cc-flag=-m32 --ld-flag=-m32' should do the tricks. > > See also http://hackage.haskell.org/trac/ghc/ticket/3681. > > HTH > -~nwn The following worked like a charm: cabal install --hsc2hs-options='--cc-flag=-m32 --ld-flag=-m32' Thanks for the tip. Antoine From greg at gregorycollins.net Sat Nov 28 18:30:04 2009 From: greg at gregorycollins.net (Gregory Collins) Date: Sat Nov 28 18:05:00 2009 Subject: GHC 6.12 + zlib + Mac OS 10.6 In-Reply-To: <694519c50911281500n17032304u310308fd2f404c1@mail.gmail.com> (Antoine Latter's message of "Sat, 28 Nov 2009 17:00:57 -0600") References: <694519c50911281301j51fa67bv88aee368d93f92dd@mail.gmail.com> <694519c50911281500n17032304u310308fd2f404c1@mail.gmail.com> Message-ID: <87638ucjnn.fsf@gregorycollins.net> Antoine Latter writes: > On Sat, Nov 28, 2009 at 3:54 PM, Yusaku Hashimoto wrote: >> I think you installed zlib without proper flags to link with 32-bit >> libraries. configuring with ./Setup configure >> --with-hsc2hs='--cc-flag=-m32 --ld-flag=-m32' should do the tricks. >> >> See also http://hackage.haskell.org/trac/ghc/ticket/3681. >> >> HTH >> -~nwn > > The following worked like a charm: > > cabal install --hsc2hs-options='--cc-flag=-m32 --ld-flag=-m32' You can also patch your hsc2hs wrapper to read: ... exec /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/hsc2hs $tflag $HSC2HS_EXTRA --cflag="-m32" --lflag="-m32" ${1+"$@"} "$Iflag" G -- Gregory Collins From nonowarn at gmail.com Sat Nov 28 20:27:05 2009 From: nonowarn at gmail.com (Yusaku Hashimoto) Date: Sat Nov 28 20:01:58 2009 Subject: GHC 6.12 + zlib + Mac OS 10.6 In-Reply-To: <694519c50911281500n17032304u310308fd2f404c1@mail.gmail.com> References: <694519c50911281301j51fa67bv88aee368d93f92dd@mail.gmail.com> <694519c50911281500n17032304u310308fd2f404c1@mail.gmail.com> Message-ID: I had wrote last mail without verifications, so ./Setup configure --hsc2hs-options='--cflag=-m32 --lflag=-m32' is correct. But I'm glad to know you got working fine with zlib :) ~-nwn On Sun, Nov 29, 2009 at 8:00 AM, Antoine Latter wrote: > On Sat, Nov 28, 2009 at 3:54 PM, Yusaku Hashimoto wrote: >> I think you installed zlib without proper flags to link with 32-bit >> libraries. configuring with ./Setup configure >> --with-hsc2hs='--cc-flag=-m32 --ld-flag=-m32' should do the tricks. >> >> See also http://hackage.haskell.org/trac/ghc/ticket/3681. >> >> HTH >> -~nwn > > The following worked like a charm: > > cabal install --hsc2hs-options='--cc-flag=-m32 --ld-flag=-m32' > > Thanks for the tip. > > Antoine > From duncan.coutts at googlemail.com Sun Nov 29 08:03:06 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Sun Nov 29 07:38:00 2009 Subject: MTL vs Transformers. Any status update? In-Reply-To: <20091128165650.GA15637@soi.city.ac.uk> References: <20091127081650.fd48e441.mle+hs@mega-nerd.com> <20091127003302.GA29911@soi.city.ac.uk> <1259426449.4896.74853.camel@localhost> <20091128165650.GA15637@soi.city.ac.uk> Message-ID: <1259499786.4896.79853.camel@localhost> On Sat, 2009-11-28 at 16:56 +0000, Ross Paterson wrote: > On Sat, Nov 28, 2009 at 04:40:49PM +0000, Duncan Coutts wrote: > > Could someone remind me why it's better for use to ask everyone to > > switch to monads-fd / transformers rather than to mtl-2? Does that make > > the transition easier? > > The problem is that transformers and mtl use the same module names, > such as Control.Monad.Identity. Unless one of these packages is hidden, > people using ghci or ghc --make will have problems. Right, so having transformers + mtl is bad, but why do we want to end up with a situation where we have both? If you've all agreed what should go into the new monad package, can't we call that mtl-2 ? Why would we want to define things in one package and re-export them in another? Duncan From ross at soi.city.ac.uk Sun Nov 29 08:35:30 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sun Nov 29 08:10:59 2009 Subject: MTL vs Transformers. Any status update? In-Reply-To: <1259499786.4896.79853.camel@localhost> References: <20091127081650.fd48e441.mle+hs@mega-nerd.com> <20091127003302.GA29911@soi.city.ac.uk> <1259426449.4896.74853.camel@localhost> <20091128165650.GA15637@soi.city.ac.uk> <1259499786.4896.79853.camel@localhost> Message-ID: <20091129133530.GA10045@soi.city.ac.uk> On Sun, Nov 29, 2009 at 01:03:06PM +0000, Duncan Coutts wrote: > On Sat, 2009-11-28 at 16:56 +0000, Ross Paterson wrote: > > On Sat, Nov 28, 2009 at 04:40:49PM +0000, Duncan Coutts wrote: > > > Could someone remind me why it's better for use to ask everyone to > > > switch to monads-fd / transformers rather than to mtl-2? Does that make > > > the transition easier? > > > > The problem is that transformers and mtl use the same module names, > > such as Control.Monad.Identity. Unless one of these packages is hidden, > > people using ghci or ghc --make will have problems. > > Right, so having transformers + mtl is bad, but why do we want to end up > with a situation where we have both? If you've all agreed what should go > into the new monad package, can't we call that mtl-2 ? Why would we want > to define things in one package and re-export them in another? Because there is not one new monad package, but two. The idea is to split the mtl package to decouple monad transformers from functional dependencies. The transformers part can then be used in Haskell 98 code, or with type classes using type functions. Exposed modules from mtl are split between the resulting two packages, so neither is a replacement for mtl-1. As I said above, having both would be a transitional arrangement, on the way to replacing mtl with the two packages split from it. mtl-2 is an attempt to smooth that transition, but it would eventually go away. From greg at gregorycollins.net Sun Nov 29 12:08:18 2009 From: greg at gregorycollins.net (Gregory Collins) Date: Sun Nov 29 11:43:10 2009 Subject: MTL vs Transformers. Any status update? In-Reply-To: <1259499786.4896.79853.camel@localhost> (Duncan Coutts's message of "Sun, 29 Nov 2009 13:03:06 +0000") References: <20091127081650.fd48e441.mle+hs@mega-nerd.com> <20091127003302.GA29911@soi.city.ac.uk> <1259426449.4896.74853.camel@localhost> <20091128165650.GA15637@soi.city.ac.uk> <1259499786.4896.79853.camel@localhost> Message-ID: <87tywdb6nx.fsf@gregorycollins.net> Duncan Coutts writes: > Right, so having transformers + mtl is bad, but why do we want to end > up with a situation where we have both? If you've all agreed what > should go into the new monad package, can't we call that mtl-2 ? Why > would we want to define things in one package and re-export them in > another? +1. G -- Gregory Collins From duncan.coutts at googlemail.com Sun Nov 29 14:02:22 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Sun Nov 29 13:37:16 2009 Subject: MTL vs Transformers. Any status update? In-Reply-To: <20091129133530.GA10045@soi.city.ac.uk> References: <20091127081650.fd48e441.mle+hs@mega-nerd.com> <20091127003302.GA29911@soi.city.ac.uk> <1259426449.4896.74853.camel@localhost> <20091128165650.GA15637@soi.city.ac.uk> <1259499786.4896.79853.camel@localhost> <20091129133530.GA10045@soi.city.ac.uk> Message-ID: <1259521342.4896.81324.camel@localhost> On Sun, 2009-11-29 at 13:35 +0000, Ross Paterson wrote: > On Sun, Nov 29, 2009 at 01:03:06PM +0000, Duncan Coutts wrote: > > On Sat, 2009-11-28 at 16:56 +0000, Ross Paterson wrote: > > > On Sat, Nov 28, 2009 at 04:40:49PM +0000, Duncan Coutts wrote: > > > > Could someone remind me why it's better for use to ask everyone to > > > > switch to monads-fd / transformers rather than to mtl-2? Does that make > > > > the transition easier? > > > > > > The problem is that transformers and mtl use the same module names, > > > such as Control.Monad.Identity. Unless one of these packages is hidden, > > > people using ghci or ghc --make will have problems. > > > > Right, so having transformers + mtl is bad, but why do we want to end up > > with a situation where we have both? If you've all agreed what should go > > into the new monad package, can't we call that mtl-2 ? Why would we want > > to define things in one package and re-export them in another? > > Because there is not one new monad package, but two. The idea is to > split the mtl package to decouple monad transformers from functional > dependencies. The transformers part can then be used in Haskell 98 code, > or with type classes using type functions. Exposed modules from mtl are > split between the resulting two packages, so neither is a replacement for > mtl-1. As I said above, having both would be a transitional arrangement, > on the way to replacing mtl with the two packages split from it. mtl-2 > is an attempt to smooth that transition, but it would eventually go away. Ok, how about this: transformers H98 bits, registered hidden by default mtl 2 re-exports transformers, adds type function stuff mtl-fd alternative that uses FDs, hidden by default I'm not sure what you agreed, if you chose the FD one as default then use mtl-tf as the alternative. Whichever you have chosen as the recommended stuff should be called mtl 2, because that is the easiest to explain to everyone. So all the packages now using mtl-1, move up to mtl 2. Then for packages that only want transformers, they depend on transformers. Similarly for the mtl-fd alternative (and whether that re-exports transformers or whether such packages should depend on transformers + mtl-fd is up to you). Users of ghci / ghc --make will end up using mtl 2 by default and there will be no module name clashes because transformers and mtl-fd will by hidden by default (Cabal-1.6+ can do that). The hiding does not affect cabal packages of course. Duncan From michael at snoyman.com Sun Nov 29 14:08:26 2009 From: michael at snoyman.com (Michael Snoyman) Date: Sun Nov 29 13:43:19 2009 Subject: MTL vs Transformers. Any status update? In-Reply-To: <1259521342.4896.81324.camel@localhost> References: <20091127081650.fd48e441.mle+hs@mega-nerd.com> <20091127003302.GA29911@soi.city.ac.uk> <1259426449.4896.74853.camel@localhost> <20091128165650.GA15637@soi.city.ac.uk> <1259499786.4896.79853.camel@localhost> <20091129133530.GA10045@soi.city.ac.uk> <1259521342.4896.81324.camel@localhost> Message-ID: <29bf512f0911291108o7404d83bg710bedca6189fbfe@mail.gmail.com> On Sun, Nov 29, 2009 at 9:02 PM, Duncan Coutts wrote: > On Sun, 2009-11-29 at 13:35 +0000, Ross Paterson wrote: > > On Sun, Nov 29, 2009 at 01:03:06PM +0000, Duncan Coutts wrote: > > > On Sat, 2009-11-28 at 16:56 +0000, Ross Paterson wrote: > > > > On Sat, Nov 28, 2009 at 04:40:49PM +0000, Duncan Coutts wrote: > > > > > Could someone remind me why it's better for use to ask everyone to > > > > > switch to monads-fd / transformers rather than to mtl-2? Does that > make > > > > > the transition easier? > > > > > > > > The problem is that transformers and mtl use the same module names, > > > > such as Control.Monad.Identity. Unless one of these packages is > hidden, > > > > people using ghci or ghc --make will have problems. > > > > > > Right, so having transformers + mtl is bad, but why do we want to end > up > > > with a situation where we have both? If you've all agreed what should > go > > > into the new monad package, can't we call that mtl-2 ? Why would we > want > > > to define things in one package and re-export them in another? > > > > Because there is not one new monad package, but two. The idea is to > > split the mtl package to decouple monad transformers from functional > > dependencies. The transformers part can then be used in Haskell 98 code, > > or with type classes using type functions. Exposed modules from mtl are > > split between the resulting two packages, so neither is a replacement for > > mtl-1. As I said above, having both would be a transitional arrangement, > > on the way to replacing mtl with the two packages split from it. mtl-2 > > is an attempt to smooth that transition, but it would eventually go away. > > Ok, how about this: > > transformers H98 bits, registered hidden by default > mtl 2 re-exports transformers, adds type function stuff > mtl-fd alternative that uses FDs, hidden by default > > I'm not sure what you agreed, if you chose the FD one as default then > use mtl-tf as the alternative. Whichever you have chosen as the > recommended stuff should be called mtl 2, because that is the easiest to > explain to everyone. > > So all the packages now using mtl-1, move up to mtl 2. Then for packages > that only want transformers, they depend on transformers. Similarly for > the mtl-fd alternative (and whether that re-exports transformers or > whether such packages should depend on transformers + mtl-fd is up to > you). > > Users of ghci / ghc --make will end up using mtl 2 by default and there > will be no module name clashes because transformers and mtl-fd will by > hidden by default (Cabal-1.6+ can do that). The hiding does not affect > cabal packages of course. > > Duncan > > Are you saying that mtl-2 would be the equivalent of transformers + monads-tf? That might not be a good call; monads-fd is probably more popular than monads-tf. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20091129/93a41853/attachment-0001.html From alexander.dunlap at gmail.com Sun Nov 29 14:37:45 2009 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Sun Nov 29 14:12:54 2009 Subject: MTL vs Transformers. Any status update? In-Reply-To: <29bf512f0911291108o7404d83bg710bedca6189fbfe@mail.gmail.com> References: <20091127081650.fd48e441.mle+hs@mega-nerd.com> <20091127003302.GA29911@soi.city.ac.uk> <1259426449.4896.74853.camel@localhost> <20091128165650.GA15637@soi.city.ac.uk> <1259499786.4896.79853.camel@localhost> <20091129133530.GA10045@soi.city.ac.uk> <1259521342.4896.81324.camel@localhost> <29bf512f0911291108o7404d83bg710bedca6189fbfe@mail.gmail.com> Message-ID: <57526e770911291137g3b6498fg4cb303fd47c255de@mail.gmail.com> On Sun, Nov 29, 2009 at 11:08 AM, Michael Snoyman wrote: > > > On Sun, Nov 29, 2009 at 9:02 PM, Duncan Coutts > wrote: >> >> On Sun, 2009-11-29 at 13:35 +0000, Ross Paterson wrote: >> > On Sun, Nov 29, 2009 at 01:03:06PM +0000, Duncan Coutts wrote: >> > > On Sat, 2009-11-28 at 16:56 +0000, Ross Paterson wrote: >> > > > On Sat, Nov 28, 2009 at 04:40:49PM +0000, Duncan Coutts wrote: >> > > > > Could someone remind me why it's better for use to ask everyone to >> > > > > switch to monads-fd / transformers rather than to mtl-2? Does that >> > > > > make >> > > > > the transition easier? >> > > > >> > > > The problem is that transformers and mtl use the same module names, >> > > > such as Control.Monad.Identity. ?Unless one of these packages is >> > > > hidden, >> > > > people using ghci or ghc --make will have problems. >> > > >> > > Right, so having transformers + mtl is bad, but why do we want to end >> > > up >> > > with a situation where we have both? If you've all agreed what should >> > > go >> > > into the new monad package, can't we call that mtl-2 ? Why would we >> > > want >> > > to define things in one package and re-export them in another? >> > >> > Because there is not one new monad package, but two. ?The idea is to >> > split the mtl package to decouple monad transformers from functional >> > dependencies. ?The transformers part can then be used in Haskell 98 >> > code, >> > or with type classes using type functions. ?Exposed modules from mtl are >> > split between the resulting two packages, so neither is a replacement >> > for >> > mtl-1. ?As I said above, having both would be a transitional >> > arrangement, >> > on the way to replacing mtl with the two packages split from it. ?mtl-2 >> > is an attempt to smooth that transition, but it would eventually go >> > away. >> >> Ok, how about this: >> >> transformers ? ?H98 bits, registered hidden by default >> mtl 2 ? ? ? ? ? re-exports transformers, adds type function stuff >> mtl-fd ? ? ? ? ?alternative that uses FDs, hidden by default >> >> I'm not sure what you agreed, if you chose the FD one as default then >> use mtl-tf as the alternative. Whichever you have chosen as the >> recommended stuff should be called mtl 2, because that is the easiest to >> explain to everyone. >> >> So all the packages now using mtl-1, move up to mtl 2. Then for packages >> that only want transformers, they depend on transformers. Similarly for >> the mtl-fd alternative (and whether that re-exports transformers or >> whether such packages should depend on transformers + mtl-fd is up to >> you). >> >> Users of ghci / ghc --make will end up using mtl 2 by default and there >> will be no module name clashes because transformers and mtl-fd will by >> hidden by default (Cabal-1.6+ can do that). The hiding does not affect >> cabal packages of course. >> >> Duncan >> > Are you saying that mtl-2 would be the equivalent of transformers + > monads-tf? That might not be a good call; monads-fd is probably more popular > than monads-tf. > > Michael > What is the plan for letting the two co-exist? Is everyone going to have to write instances that work with both monads-{tf,fd} and then export duplicate functions that have monad classes in their signatures? It seems like if we can't have a nice way to use both, we ought to just pick one and deprecate the other. Alex From michael at snoyman.com Sun Nov 29 14:40:10 2009 From: michael at snoyman.com (Michael Snoyman) Date: Sun Nov 29 14:15:01 2009 Subject: MTL vs Transformers. Any status update? In-Reply-To: <57526e770911291137g3b6498fg4cb303fd47c255de@mail.gmail.com> References: <20091127081650.fd48e441.mle+hs@mega-nerd.com> <20091127003302.GA29911@soi.city.ac.uk> <1259426449.4896.74853.camel@localhost> <20091128165650.GA15637@soi.city.ac.uk> <1259499786.4896.79853.camel@localhost> <20091129133530.GA10045@soi.city.ac.uk> <1259521342.4896.81324.camel@localhost> <29bf512f0911291108o7404d83bg710bedca6189fbfe@mail.gmail.com> <57526e770911291137g3b6498fg4cb303fd47c255de@mail.gmail.com> Message-ID: <29bf512f0911291140p44d29038n3a38fccef44e16c1@mail.gmail.com> On Sun, Nov 29, 2009 at 9:37 PM, Alexander Dunlap < alexander.dunlap@gmail.com> wrote: > On Sun, Nov 29, 2009 at 11:08 AM, Michael Snoyman > wrote: > > > > > > On Sun, Nov 29, 2009 at 9:02 PM, Duncan Coutts > > wrote: > >> > >> On Sun, 2009-11-29 at 13:35 +0000, Ross Paterson wrote: > >> > On Sun, Nov 29, 2009 at 01:03:06PM +0000, Duncan Coutts wrote: > >> > > On Sat, 2009-11-28 at 16:56 +0000, Ross Paterson wrote: > >> > > > On Sat, Nov 28, 2009 at 04:40:49PM +0000, Duncan Coutts wrote: > >> > > > > Could someone remind me why it's better for use to ask everyone > to > >> > > > > switch to monads-fd / transformers rather than to mtl-2? Does > that > >> > > > > make > >> > > > > the transition easier? > >> > > > > >> > > > The problem is that transformers and mtl use the same module > names, > >> > > > such as Control.Monad.Identity. Unless one of these packages is > >> > > > hidden, > >> > > > people using ghci or ghc --make will have problems. > >> > > > >> > > Right, so having transformers + mtl is bad, but why do we want to > end > >> > > up > >> > > with a situation where we have both? If you've all agreed what > should > >> > > go > >> > > into the new monad package, can't we call that mtl-2 ? Why would we > >> > > want > >> > > to define things in one package and re-export them in another? > >> > > >> > Because there is not one new monad package, but two. The idea is to > >> > split the mtl package to decouple monad transformers from functional > >> > dependencies. The transformers part can then be used in Haskell 98 > >> > code, > >> > or with type classes using type functions. Exposed modules from mtl > are > >> > split between the resulting two packages, so neither is a replacement > >> > for > >> > mtl-1. As I said above, having both would be a transitional > >> > arrangement, > >> > on the way to replacing mtl with the two packages split from it. > mtl-2 > >> > is an attempt to smooth that transition, but it would eventually go > >> > away. > >> > >> Ok, how about this: > >> > >> transformers H98 bits, registered hidden by default > >> mtl 2 re-exports transformers, adds type function stuff > >> mtl-fd alternative that uses FDs, hidden by default > >> > >> I'm not sure what you agreed, if you chose the FD one as default then > >> use mtl-tf as the alternative. Whichever you have chosen as the > >> recommended stuff should be called mtl 2, because that is the easiest to > >> explain to everyone. > >> > >> So all the packages now using mtl-1, move up to mtl 2. Then for packages > >> that only want transformers, they depend on transformers. Similarly for > >> the mtl-fd alternative (and whether that re-exports transformers or > >> whether such packages should depend on transformers + mtl-fd is up to > >> you). > >> > >> Users of ghci / ghc --make will end up using mtl 2 by default and there > >> will be no module name clashes because transformers and mtl-fd will by > >> hidden by default (Cabal-1.6+ can do that). The hiding does not affect > >> cabal packages of course. > >> > >> Duncan > >> > > Are you saying that mtl-2 would be the equivalent of transformers + > > monads-tf? That might not be a good call; monads-fd is probably more > popular > > than monads-tf. > > > > Michael > > > > What is the plan for letting the two co-exist? Is everyone going to > have to write instances that work with both monads-{tf,fd} and then > export duplicate functions that have monad classes in their > signatures? It seems like if we can't have a nice way to use both, we > ought to just pick one and deprecate the other. > > Alex > Sounds reasonable to me. Shall we take a vote on which one it'll be? If FunDeps is really being deprecated, it would appear that tf is the way forward... Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20091129/299a1789/attachment.html From duncan.coutts at googlemail.com Sun Nov 29 14:48:56 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Sun Nov 29 14:23:48 2009 Subject: MTL vs Transformers. Any status update? In-Reply-To: <29bf512f0911291108o7404d83bg710bedca6189fbfe@mail.gmail.com> References: <20091127081650.fd48e441.mle+hs@mega-nerd.com> <20091127003302.GA29911@soi.city.ac.uk> <1259426449.4896.74853.camel@localhost> <20091128165650.GA15637@soi.city.ac.uk> <1259499786.4896.79853.camel@localhost> <20091129133530.GA10045@soi.city.ac.uk> <1259521342.4896.81324.camel@localhost> <29bf512f0911291108o7404d83bg710bedca6189fbfe@mail.gmail.com> Message-ID: <1259524136.4896.81549.camel@localhost> On Sun, 2009-11-29 at 21:08 +0200, Michael Snoyman wrote: >> Ok, how about this: >> >> transformers H98 bits, registered hidden by default >> mtl 2 re-exports transformers, adds type function stuff >> mtl-fd alternative that uses FDs, hidden by default >> > Are you saying that mtl-2 would be the equivalent of transformers + > monads-tf? That might not be a good call; monads-fd is probably more > popular than monads-tf. Yes mtl-2 would be transformers + monads-${the-right-one} Though more precisely, it'd re-export transformers and contain monads-${the-right-one}. I'm not really saying whether it should be the tf or fd version. I've not been taking part in that discussion. But other people have been discussing it and whichever one it is that they agree is the right default, that one should be labelled as mtl version 2. Also, I should say that it would be wrong to push the choice of FDs/TFs onto everyone. We should just pick one. Some people know the difference and can select an alternative. Everyone else just wants to use the same one as everyone else is using. Duncan From valery.vv at gmail.com Sun Nov 29 16:30:14 2009 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Sun Nov 29 16:05:04 2009 Subject: #562: cabal-install update fails going through a HTTP proxy In-Reply-To: <4B11A1C7.3030201@gmail.com> References: <87ab0rc475.fsf@gmail.com> <4AFF2AC3.8020403@gmail.com> <4B01531E.8050804@gmail.com> <4B11A1C7.3030201@gmail.com> Message-ID: Sigbjorn Finne wrote: > > Despite repeated attempts from this end, I am unable to reproduce > this via local proxies. > > Hence chasing down whatever problem is biting you (and others) is > tricky without a repro case. I'll try this change tomorrow: -----BEGIN DIFF----- diff --git a/Network/TCP.hs b/Network/TCP.hs index 7d3dbe7..04b8e2a 100644 --- a/Network/TCP.hs +++ b/Network/TCP.hs @@ -34,7 +34,7 @@ module Network.TCP import Network.BSD (getHostByName, hostAddresses) import Network.Socket - ( Socket, SockAddr(SockAddrInet), SocketOption(KeepAlive) + ( Socket, SockAddr(SockAddrInet), SocketOption(KeepAlive, Linger) , SocketType(Stream), inet_addr, connect , shutdown, ShutdownCmd(..) , sClose, setSocketOption, getPeerName @@ -189,6 +189,7 @@ openTCPConnection_ :: BufferType ty => String -> Int -> Bool - openTCPConnection_ uri port stashInput = do s <- socket AF_INET Stream 6 setSocketOption s KeepAlive 1 + setSocketOption s Linger 5 hostA <- getHostAddr uri let a = SockAddrInet (toEnum port) hostA catchIO (connect s a) (\e -> sClose s >> ioError e) -----END DIFF----- | If there is still data waiting to be transmitted over the | connection, normally `close' tries to complete this transmission. | You can control this behavior using the `SO_LINGER' socket option to | specify a timeout period; see *note _Socket Options_. [http://www.gnu.org/s/libc/manual/html_node/Closing-a-Socket.html] -- vvv From ekmett at gmail.com Sun Nov 29 19:29:47 2009 From: ekmett at gmail.com (Edward Kmett) Date: Sun Nov 29 19:04:36 2009 Subject: MTL vs Transformers. Any status update? In-Reply-To: <1259524136.4896.81549.camel@localhost> References: <20091127081650.fd48e441.mle+hs@mega-nerd.com> <20091127003302.GA29911@soi.city.ac.uk> <1259426449.4896.74853.camel@localhost> <20091128165650.GA15637@soi.city.ac.uk> <1259499786.4896.79853.camel@localhost> <20091129133530.GA10045@soi.city.ac.uk> <1259521342.4896.81324.camel@localhost> <29bf512f0911291108o7404d83bg710bedca6189fbfe@mail.gmail.com> <1259524136.4896.81549.camel@localhost> Message-ID: <7fb8f82f0911291629t4f225b46ufb214331c0f5decc@mail.gmail.com> Overall, it sounds good. I would suggest that perhaps maintaining the fundep version as the default exported by mtl-2 might be nicer for backwards and simplicity reasons. A lot of code could quite reasonably work with an mtl constraint that spans both versions if mtl-2 was the fundep version as long as it doesn't provide instances for the base monads, otherwise the dependency section of their cabal file would get complicated, having to switch packages at the 2.0 mark. That way existing code would continue to work across the version bump if it didn't care about the type synonym issue for State, Reader, etc. The question then becomes how to shuffle things around namespace wise? As a straw man proposal to get things started: transformers: Control.Monad.Foo.Transformer - for the actual data type for FooT mtl 2: Control.Monad.Foo.Class - exports just the fundep-based typeclass and no instances, like now. Control.Monad.Foo - exports the instances for the fundep based version and re-exports the Transformer and Class module contents. Then the type-family package can provide: mtl-tf: Control.Monad.Foo.Family.Class - exports just the type-family based typeclass Control.Monad.Foo.Family - exports the instances of the typefamily base version and re-exports the Transformer and Family.Class modules This will safely let most libraries just use a constraint on mtl >= 1.2 && <= 2.1 in which case their code works across both versions, and if someone wants to use mtl-tf for clarity in their code, it will introduce no complications regardless of what libraries they import as long as those libraries can support both versions. The final issue is whether or not it is a good idea to eliminate the simpler non-transformer versions of the monads. Without them, libraries that provide instances for the various monads cannot provide instances for State and StateT in a way that lets them work compatibly with both versions. So, an issue that I would like to talk about separately is if we _should_ be dropping the basic State, Reader, Writer, etc. constructors. They have definite pedagogical value, and have easier to understand behavior for introductory purposes. If we kept those then ALL code that worked with mtl 1.2 would be compatible with mtl 2, which strikes me as a desirable property. This has the benefit that it is easier to write libraries that export instances. I think we would be remiss in not at least considering the issue. On the other hand, I don't know how many libraries provide instances for the monads in the MTL. I have a few in my monoids library, but I'd be willing to go either way. -Edward Kmett On Sun, Nov 29, 2009 at 2:48 PM, Duncan Coutts wrote: > On Sun, 2009-11-29 at 21:08 +0200, Michael Snoyman wrote: > > >> Ok, how about this: > >> > >> transformers H98 bits, registered hidden by default > >> mtl 2 re-exports transformers, adds type function stuff > >> mtl-fd alternative that uses FDs, hidden by default > >> > > > Are you saying that mtl-2 would be the equivalent of transformers + > > monads-tf? That might not be a good call; monads-fd is probably more > > popular than monads-tf. > > Yes mtl-2 would be transformers + monads-${the-right-one} > > Though more precisely, it'd re-export transformers and contain > monads-${the-right-one}. > > I'm not really saying whether it should be the tf or fd version. I've > not been taking part in that discussion. > > But other people have been discussing it and whichever one it is that > they agree is the right default, that one should be labelled as mtl > version 2. > > Also, I should say that it would be wrong to push the choice of FDs/TFs > onto everyone. We should just pick one. Some people know the difference > and can select an alternative. Everyone else just wants to use the same > one as everyone else is using. > > Duncan > > _______________________________________________ > 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/20091129/367a4934/attachment-0001.html From chak at cse.unsw.edu.au Sun Nov 29 22:08:42 2009 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Nov 29 21:43:40 2009 Subject: GHC 6.12 + zlib + Mac OS 10.6 In-Reply-To: <694519c50911281500n17032304u310308fd2f404c1@mail.gmail.com> References: <694519c50911281301j51fa67bv88aee368d93f92dd@mail.gmail.com> <694519c50911281500n17032304u310308fd2f404c1@mail.gmail.com> Message-ID: <779BF090-FEE9-4B3E-B69E-9FDA9EB8F7E7@cse.unsw.edu.au> Antoine Latter: > On Sat, Nov 28, 2009 at 3:54 PM, Yusaku Hashimoto wrote: >> I think you installed zlib without proper flags to link with 32-bit >> libraries. configuring with ./Setup configure >> --with-hsc2hs='--cc-flag=-m32 --ld-flag=-m32' should do the tricks. >> >> See also http://hackage.haskell.org/trac/ghc/ticket/3681. >> >> HTH >> -~nwn > > The following worked like a charm: > > cabal install --hsc2hs-options='--cc-flag=-m32 --ld-flag=-m32' Which version of 6.12 are you running? These options or manually patching the hsc2hs wrapper should not be necessary with 6.12 anymore. (They are only a temporary workaround to use the old 6.10 release on Snow Leopard.) Manuel From aslatter at gmail.com Sun Nov 29 23:49:17 2009 From: aslatter at gmail.com (Antoine Latter) Date: Sun Nov 29 23:24:09 2009 Subject: GHC 6.12 + zlib + Mac OS 10.6 In-Reply-To: <779BF090-FEE9-4B3E-B69E-9FDA9EB8F7E7@cse.unsw.edu.au> References: <694519c50911281301j51fa67bv88aee368d93f92dd@mail.gmail.com> <694519c50911281500n17032304u310308fd2f404c1@mail.gmail.com> <779BF090-FEE9-4B3E-B69E-9FDA9EB8F7E7@cse.unsw.edu.au> Message-ID: <694519c50911292049g587dbcbat5902667b94290349@mail.gmail.com> On Sun, Nov 29, 2009 at 9:08 PM, Manuel M T Chakravarty wrote: > > Which version of 6.12 are you running? ?These options or manually patching the hsc2hs wrapper should not be necessary with 6.12 anymore. ?(They are only a temporary workaround to use the old 6.10 release on Snow Leopard.) > > Manuel I built it within the past few days, I'm not sure why the version number says 1120. $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.12.0.20091120 Installed from darcs via "configre --prefix=${HOME}/usr && make && make install" and such. Could an unpatched hsc2hs wrapper have been left around by my old GHC 6.10 installation? Antoine From nonowarn at gmail.com Mon Nov 30 02:25:55 2009 From: nonowarn at gmail.com (Yusaku Hashimoto) Date: Mon Nov 30 02:00:46 2009 Subject: GHC 6.12 + zlib + Mac OS 10.6 In-Reply-To: <694519c50911292049g587dbcbat5902667b94290349@mail.gmail.com> References: <694519c50911281301j51fa67bv88aee368d93f92dd@mail.gmail.com> <694519c50911281500n17032304u310308fd2f404c1@mail.gmail.com> <779BF090-FEE9-4B3E-B69E-9FDA9EB8F7E7@cse.unsw.edu.au> <694519c50911292049g587dbcbat5902667b94290349@mail.gmail.com> Message-ID: This was reproduced on rc2, too. I installed ghc-6.12 rc2 by the installer. As the ticket I mentioned[1] says, The problem is the flags to build 32-bit binaries is not passed to the hsc2hs executable when the hsc2hs wrapper get any --cc parameter. Cabal passes --cc parameter to the wrapper to tell where gcc is. So when building a package with Cabal, hsc2hs goes wrong. [1]: http://hackage.haskell.org/trac/ghc/ticket/3681 --nwn On Mon, Nov 30, 2009 at 1:49 PM, Antoine Latter wrote: > On Sun, Nov 29, 2009 at 9:08 PM, Manuel M T Chakravarty > wrote: >> >> Which version of 6.12 are you running? ?These options or manually patching the hsc2hs wrapper should not be necessary with 6.12 anymore. ?(They are only a temporary workaround to use the old 6.10 release on Snow Leopard.) >> >> Manuel > > I built it within the past few days, I'm not sure why the version > number says 1120. > > $ ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.12.0.20091120 > > Installed from darcs via "configre --prefix=${HOME}/usr && make && > make install" and such. > > Could an unpatched hsc2hs wrapper have been left around by my old GHC > 6.10 installation? > > Antoine > From wren at community.haskell.org Mon Nov 30 03:03:08 2009 From: wren at community.haskell.org (wren ng thornton) Date: Mon Nov 30 02:37:59 2009 Subject: MTL vs Transformers. Any status update? In-Reply-To: <7fb8f82f0911291629t4f225b46ufb214331c0f5decc@mail.gmail.com> References: <20091127081650.fd48e441.mle+hs@mega-nerd.com> <20091127003302.GA29911@soi.city.ac.uk> <1259426449.4896.74853.camel@localhost> <20091128165650.GA15637@soi.city.ac.uk> <1259499786.4896.79853.camel@localhost> <20091129133530.GA10045@soi.city.ac.uk> <1259521342.4896.81324.camel@localhost> <29bf512f0911291108o7404d83bg710bedca6189fbfe@mail.gmail.com> <1259524136.4896.81549.camel@localhost> <7fb8f82f0911291629t4f225b46ufb214331c0f5decc@mail.gmail.com> Message-ID: <4B137C3C.2010709@community.haskell.org> Edward Kmett wrote: > As a straw man proposal to get things started: > > transformers: > Control.Monad.Foo.Transformer - for the actual data type for FooT > > mtl 2: > Control.Monad.Foo.Class - exports just the fundep-based typeclass and no > instances, like now. > Control.Monad.Foo - exports the instances for the fundep based version and > re-exports the Transformer and Class module contents. > > mtl-tf: > Control.Monad.Foo.Family.Class - exports just the type-family based > typeclass > Control.Monad.Foo.Family - exports the instances of the typefamily base > version and re-exports the Transformer and Family.Class modules > > This will safely let most libraries just use a constraint on mtl >= 1.2 && > <= 2.1 in which case their code works across both versions, and if someone > wants to use mtl-tf for clarity in their code, it will introduce no > complications regardless of what libraries they import as long as those > libraries can support both versions. It's consistent and avoids name-clashery, which is nice. But I thought transformers had everything in one file? Maybe I'm thinking of a different monad transformer library... I think keeping fundeps as the default is probably best. It maintains instance definitions in old code across the version boundary, and it also maintains support with Hugs for folks who care about that. If, in the future, the community decides that fundeps are bad and TFs are good then we can make that switch in mtl-3. Even though a lot of folks are leaning that way now, I don't think there's a clear consensus yet to deprecate fundeps. Conflating the fundep-vs-TF debate in with the mtl-vs-transformers debate is just going to drag things out longer IMO. -- Live well, ~wren From simonpj at microsoft.com Mon Nov 30 03:44:34 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Nov 30 03:19:27 2009 Subject: GHC 6.12 + zlib + Mac OS 10.6 In-Reply-To: <694519c50911281500n17032304u310308fd2f404c1@mail.gmail.com> References: <694519c50911281301j51fa67bv88aee368d93f92dd@mail.gmail.com> <694519c50911281500n17032304u310308fd2f404c1@mail.gmail.com> Message-ID: <59543203684B2244980D7E4057D5FBC10850297D@DB3EX14MBXC310.europe.corp.microsoft.com> Should this go in a FAQ? For GHC? Or for a particular architecture? Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Antoine Latter | Sent: 28 November 2009 23:01 | To: Yusaku Hashimoto | Cc: glasgow-haskell-users@haskell.org; Haskell Libraries | Subject: Re: GHC 6.12 + zlib + Mac OS 10.6 | | On Sat, Nov 28, 2009 at 3:54 PM, Yusaku Hashimoto wrote: | > I think you installed zlib without proper flags to link with 32-bit | > libraries. configuring with ./Setup configure | > --with-hsc2hs='--cc-flag=-m32 --ld-flag=-m32' should do the tricks. | > | > See also http://hackage.haskell.org/trac/ghc/ticket/3681. | > | > HTH | > -~nwn | | The following worked like a charm: | | cabal install --hsc2hs-options='--cc-flag=-m32 --ld-flag=-m32' | | Thanks for the tip. | | Antoine | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From ekmett at gmail.com Mon Nov 30 05:35:25 2009 From: ekmett at gmail.com (Edward Kmett) Date: Mon Nov 30 05:10:17 2009 Subject: MTL vs Transformers. Any status update? In-Reply-To: <4B137C3C.2010709@community.haskell.org> References: <20091127081650.fd48e441.mle+hs@mega-nerd.com> <1259426449.4896.74853.camel@localhost> <20091128165650.GA15637@soi.city.ac.uk> <1259499786.4896.79853.camel@localhost> <20091129133530.GA10045@soi.city.ac.uk> <1259521342.4896.81324.camel@localhost> <29bf512f0911291108o7404d83bg710bedca6189fbfe@mail.gmail.com> <1259524136.4896.81549.camel@localhost> <7fb8f82f0911291629t4f225b46ufb214331c0f5decc@mail.gmail.com> <4B137C3C.2010709@community.haskell.org> Message-ID: <7fb8f82f0911300235t5efabd64j45768b96433f7c94@mail.gmail.com> > > It's consistent and avoids name-clashery, which is nice. But I thought > transformers had everything in one file? Maybe I'm thinking of a different > monad transformer library... > I believe you are thinking of monadLib. -Edward Kmett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20091130/67faf4ae/attachment.html From ekmett at gmail.com Mon Nov 30 05:37:48 2009 From: ekmett at gmail.com (Edward Kmett) Date: Mon Nov 30 05:12:36 2009 Subject: MTL vs Transformers. Any status update? In-Reply-To: <4B137C3C.2010709@community.haskell.org> References: <20091127081650.fd48e441.mle+hs@mega-nerd.com> <1259426449.4896.74853.camel@localhost> <20091128165650.GA15637@soi.city.ac.uk> <1259499786.4896.79853.camel@localhost> <20091129133530.GA10045@soi.city.ac.uk> <1259521342.4896.81324.camel@localhost> <29bf512f0911291108o7404d83bg710bedca6189fbfe@mail.gmail.com> <1259524136.4896.81549.camel@localhost> <7fb8f82f0911291629t4f225b46ufb214331c0f5decc@mail.gmail.com> <4B137C3C.2010709@community.haskell.org> Message-ID: <7fb8f82f0911300237v341868d4u2002a1b2db507cf2@mail.gmail.com> On Mon, Nov 30, 2009 at 3:03 AM, wren ng thornton < wren@community.haskell.org> wrote: > Edward Kmett wrote: > >> As a straw man proposal to get things started: >> >> transformers: >> Control.Monad.Foo.Transformer - for the actual data type for FooT >> > Feel free to amend that to keep the monad transformers where they are under Control.Monad.Trans.Foo - I hadn't checked before writing that out and have no real reason to move them. -Edward Kmett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20091130/5a8e1376/attachment.html From nonowarn at gmail.com Mon Nov 30 05:38:29 2009 From: nonowarn at gmail.com (Yusaku Hashimoto) Date: Mon Nov 30 05:13:17 2009 Subject: GHC 6.12 + zlib + Mac OS 10.6 In-Reply-To: <59543203684B2244980D7E4057D5FBC10850297D@DB3EX14MBXC310.europe.corp.microsoft.com> References: <694519c50911281301j51fa67bv88aee368d93f92dd@mail.gmail.com> <694519c50911281500n17032304u310308fd2f404c1@mail.gmail.com> <59543203684B2244980D7E4057D5FBC10850297D@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: I think this is a problem for architectures in which can only build 32-bit binaries. On such architectures, hsc2hs should ensure to work for 32-bit binaries as possible. So I think hsc2hs wrapper should be fixed to give the flags if gcc is used. --nwn On Mon, Nov 30, 2009 at 5:44 PM, Simon Peyton-Jones wrote: > Should this go in a FAQ? For GHC? Or for a particular architecture? > > Simon > > | -----Original Message----- > | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- > | bounces@haskell.org] On Behalf Of Antoine Latter > | Sent: 28 November 2009 23:01 > | To: Yusaku Hashimoto > | Cc: glasgow-haskell-users@haskell.org; Haskell Libraries > | Subject: Re: GHC 6.12 + zlib + Mac OS 10.6 > | > | On Sat, Nov 28, 2009 at 3:54 PM, Yusaku Hashimoto wrote: > | > I think you installed zlib without proper flags to link with 32-bit > | > libraries. configuring with ./Setup configure > | > --with-hsc2hs='--cc-flag=-m32 --ld-flag=-m32' should do the tricks. > | > > | > See also http://hackage.haskell.org/trac/ghc/ticket/3681. > | > > | > HTH > | > -~nwn > | > | The following worked like a charm: > | > | cabal install --hsc2hs-options='--cc-flag=-m32 --ld-flag=-m32' > | > | Thanks for the tip. > | > | Antoine > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users@haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > From duncan.coutts at googlemail.com Mon Nov 30 05:41:24 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon Nov 30 05:16:15 2009 Subject: GHC 6.12 + zlib + Mac OS 10.6 In-Reply-To: <59543203684B2244980D7E4057D5FBC10850297D@DB3EX14MBXC310.europe.corp.microsoft.com> References: <694519c50911281301j51fa67bv88aee368d93f92dd@mail.gmail.com> <694519c50911281500n17032304u310308fd2f404c1@mail.gmail.com> <59543203684B2244980D7E4057D5FBC10850297D@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: <1259577684.4896.85147.camel@localhost> On Mon, 2009-11-30 at 08:44 +0000, Simon Peyton-Jones wrote: > Should this go in a FAQ? For GHC? Or for a particular architecture? For ghc-6.10, yes. It'd should be a section "GHC on OSX 10.6 (Snow Leopard)" and should describe the changes required to the shell script wrappers of ghc and hsc2hs. It should also note that none of this is necessary for ghc-6.12+. For ghc-6.12, we should just fix ticket #3681. http://hackage.haskell.org/trac/ghc/ticket/3681 Duncan From ross at soi.city.ac.uk Mon Nov 30 06:28:17 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Nov 30 06:04:02 2009 Subject: MTL vs Transformers. Any status update? In-Reply-To: <1259524136.4896.81549.camel@localhost> References: <20091127081650.fd48e441.mle+hs@mega-nerd.com> <20091127003302.GA29911@soi.city.ac.uk> <1259426449.4896.74853.camel@localhost> <20091128165650.GA15637@soi.city.ac.uk> <1259499786.4896.79853.camel@localhost> <20091129133530.GA10045@soi.city.ac.uk> <1259521342.4896.81324.camel@localhost> <29bf512f0911291108o7404d83bg710bedca6189fbfe@mail.gmail.com> <1259524136.4896.81549.camel@localhost> Message-ID: <20091130112817.GA5660@soi.city.ac.uk> On Sun, Nov 29, 2009 at 07:48:56PM +0000, Duncan Coutts wrote: > I'm not really saying whether it should be the tf or fd version. > I've not been taking part in that discussion. You haven't missed anything. I think we're a long way off being ready to make a final choice between FDs and TFs. For one thing neither of them is standard, and both monads-* packages also require other non-standard extensions. But we are at the point where we can decide to make FDs optional, though that hasn't been decided yet either. That's not to say that the HP shouldn't present a pre-packaged choice (probably FDs for some time), just that it shouldn't get in the way of alternatives. From ross at soi.city.ac.uk Mon Nov 30 06:59:57 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Nov 30 06:35:41 2009 Subject: MTL vs Transformers. Any status update? In-Reply-To: <57526e770911291137g3b6498fg4cb303fd47c255de@mail.gmail.com> References: <20091127081650.fd48e441.mle+hs@mega-nerd.com> <20091127003302.GA29911@soi.city.ac.uk> <1259426449.4896.74853.camel@localhost> <20091128165650.GA15637@soi.city.ac.uk> <1259499786.4896.79853.camel@localhost> <20091129133530.GA10045@soi.city.ac.uk> <1259521342.4896.81324.camel@localhost> <29bf512f0911291108o7404d83bg710bedca6189fbfe@mail.gmail.com> <57526e770911291137g3b6498fg4cb303fd47c255de@mail.gmail.com> Message-ID: <20091130115957.GB5660@soi.city.ac.uk> On Sun, Nov 29, 2009 at 11:37:45AM -0800, Alexander Dunlap wrote: > What is the plan for letting the two co-exist? Is everyone going to > have to write instances that work with both monads-{tf,fd} and then > export duplicate functions that have monad classes in their > signatures? Most clients just use the transformers to make composite monads, and the classes to get the operations. They can just pick one or the other for their private use. People defining and exporting their own monads will probably want to make them instances of both versions of the classes. If a package's interface uses the transformers (or the Haskell 98 classes MonadTrans and MonadIO), it will work with both monads packages. That leaves the packages that have FD or TF classes in their interfaces. From simonpj at microsoft.com Mon Nov 30 07:20:24 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Nov 30 06:55:16 2009 Subject: GHC 6.12 + zlib + Mac OS 10.6 In-Reply-To: <1259577684.4896.85147.camel@localhost> References: <694519c50911281301j51fa67bv88aee368d93f92dd@mail.gmail.com> <694519c50911281500n17032304u310308fd2f404c1@mail.gmail.com> <59543203684B2244980D7E4057D5FBC10850297D@DB3EX14MBXC310.europe.corp.microsoft.com> <1259577684.4896.85147.camel@localhost> Message-ID: <59543203684B2244980D7E4057D5FBC1085033BB@DB3EX14MBXC310.europe.corp.microsoft.com> | For ghc-6.12, we should just fix ticket #3681. OK, good. But who is "we"? Simon | -----Original Message----- | From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf | Of Duncan Coutts | Sent: 30 November 2009 10:41 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users@haskell.org; Haskell Libraries | Subject: RE: GHC 6.12 + zlib + Mac OS 10.6 | | On Mon, 2009-11-30 at 08:44 +0000, Simon Peyton-Jones wrote: | > Should this go in a FAQ? For GHC? Or for a particular architecture? | | For ghc-6.10, yes. It'd should be a section "GHC on OSX 10.6 (Snow | Leopard)" and should describe the changes required to the shell script | wrappers of ghc and hsc2hs. It should also note that none of this is | necessary for ghc-6.12+. | | For ghc-6.12, we should just fix ticket #3681. | | http://hackage.haskell.org/trac/ghc/ticket/3681 | | | Duncan | | _______________________________________________ | Libraries mailing list | Libraries@haskell.org | http://www.haskell.org/mailman/listinfo/libraries From duncan.coutts at googlemail.com Mon Nov 30 07:22:08 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon Nov 30 06:57:00 2009 Subject: GHC 6.12 + zlib + Mac OS 10.6 In-Reply-To: <59543203684B2244980D7E4057D5FBC1085033BB@DB3EX14MBXC310.europe.corp.microsoft.com> References: <694519c50911281301j51fa67bv88aee368d93f92dd@mail.gmail.com> <694519c50911281500n17032304u310308fd2f404c1@mail.gmail.com> <59543203684B2244980D7E4057D5FBC10850297D@DB3EX14MBXC310.europe.corp.microsoft.com> <1259577684.4896.85147.camel@localhost> <59543203684B2244980D7E4057D5FBC1085033BB@DB3EX14MBXC310.europe.corp.microsoft.com> Message-ID: <1259583728.4896.85584.camel@localhost> On Mon, 2009-11-30 at 12:20 +0000, Simon Peyton-Jones wrote: > | For ghc-6.12, we should just fix ticket #3681. > > OK, good. But who is "we"? I think the short-term fix is just to change the hsc2hs wrapper script. So that'd be Ian. Longer term we might want to do it differently to allow a single hsc2hs instance to be used to target either 32 or 64bit ABIs on the same platform. Duncan From valery.vv at gmail.com Mon Nov 30 08:32:56 2009 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Mon Nov 30 08:07:45 2009 Subject: [network] getAddrInfo: invalid haddock (+ patch) Message-ID: Example in the haddock documentation for `getAddrInfo' function is rendered incorrectly: http://is.gd/57LgX -----BEGIN PATCH----- --- Network/Socket.hsc.orig 2009-11-30 15:08:57.869477201 +0200 +++ Network/Socket.hsc 2009-11-30 15:08:28.328452505 +0200 @@ -1972,9 +1972,10 @@ -- to make partial application easier. -- -- Example: +-- -- @ -- let hints = defaultHints { addrFlags = [AI_ADDRCONFIG, AI_CANONNAME] } --- addrs <- getAddrInfo (Just hints) (Just "www.haskell.org") (Just "http") +-- addrs <- getAddrInfo (Just hints) (Just \"www.haskell.org\") (Just \"http\") -- let addr = head addrs -- sock <- socket (addrFamily addr) (addrSocketType addr) (addrProtocol addr) -- connect sock (addrAddress addr) -----END PATCH----- -- vvv -------------- next part -------------- A non-text attachment was scrubbed... Name: getAddrInfo-haddock.patch Type: text/x-patch Size: 598 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20091130/7bfd6676/getAddrInfo-haddock.bin From valery.vv at gmail.com Mon Nov 30 08:40:24 2009 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Mon Nov 30 08:15:13 2009 Subject: [network] new tickets submission unavailable Message-ID: > Example in the haddock documentation for `getAddrInfo' function is > rendered incorrectly And what's the purpose of issue tracking system, which even _registered_ user cannot create a ticket for? http://trac.haskell.org/network/wiki "What the bug?" -- vvv From marlowsd at gmail.com Mon Nov 30 09:45:48 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 30 09:20:56 2009 Subject: Guarantees regarding finalizers In-Reply-To: <13dd2de20911260441x7751680cwae75f7fee00fe8d6@mail.gmail.com> References: <13dd2de20911260435q29619d0av4b12661dd8931478@mail.gmail.com> <13dd2de20911260441x7751680cwae75f7fee00fe8d6@mail.gmail.com> Message-ID: <4B13DA9C.2070204@gmail.com> On 26/11/2009 12:41, Mietek B?k wrote: > I'm writing a binding to a C library, which requires an explicit > cleanup call before program termination. While looking for a way to > automatize this, I noticed a discrepancy in the standard library > documentation. > > The Foreign.Concurrent documentation states: > "The only guarantee is that the finalizer runs before the program terminates." > (http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign-Concurrent.html) > > On the other hand, the Foreign.ForeignPtr documentation states: > "Indeed, there is no guarantee that the finalizer is executed at all; > a program may exit with finalizers outstanding." > (http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign-ForeignPtr.html) > > Note that Foreign.Concurrent.newForeignPtr is implemented in GHC as > GHC.ForeignPtr.newConcForeignPtr. The newConcForeignPtr comments also > state: > "There is no guarantee of promptness, and in fact there is no > guarantee that the finalizer will eventually run at all." > (http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-ForeignPtr.html) > > As much as I would like the Foreign.Concurrent guarantee to be true, > this seems to me like a documentation bug. The docs are rather backward. Foreign.ForeignPtr finalizers are guaranteed to run, Foreign.Concurrent finalizers are not. I'll fix the docs, thanks for the report. Cheers, Simon From valery.vv at gmail.com Mon Nov 30 09:49:13 2009 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Mon Nov 30 09:24:01 2009 Subject: [network] `setSocketOption' fails with `Linger' option Message-ID: See http://is.gd/57Ptu (Network.Socket.setSocketOption). `setSocketOption' uses FFI binding to setsockopt(2), named `c_setsockopt'. > foreign import CALLCONV unsafe "setsockopt" > c_setsockopt :: CInt -> CInt -> CInt -> Ptr CInt -> CInt -> IO CInt The binding treats OPTVAL (4th argument) as a pointer to `int'. This is mostly fine but not when `SO_LINGER' option is being set. In the latter case OPTVAL must be a pointer to `struct linger'. [1] [1] http://www.gnu.org/s/libc/manual/html_node/Socket_002dLevel-Options.html Haskell programs trying to set SO_LINGER socket option will successfully compile but fail in runtime. $ runhaskell socket-linger.hs || echo X $ runhaskell -DLINGER socket-linger.hs || echo X socket-linger.hs: setSocketOption: invalid argument (Invalid argument) X $ gcc -g -Wall -W -o /tmp/1 socket-linger.c && /tmp/1 || echo X $ gcc -g -DLINGER_AS_INT -Wall -W -o /tmp/1 socket-linger.c && /tmp/1 || echo X setsockopt: Invalid argument X (See attached files `socket-linger.c', `socket-linger.hs'.) The necessity of `SO_LINGER' option is controversial (see [2]). I think it is better to comment the `Linger' constructor out of Network/Socket.hsc. [2] http://www.developerweb.net/forum/archive/index.php/t-2982.html Cheers. -- vvv -------------- next part -------------- A non-text attachment was scrubbed... Name: socket-linger.hs Type: text/x-haskell Size: 565 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20091130/6221433c/socket-linger.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: socket-linger.c Type: application/octet-stream Size: 1307 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20091130/6221433c/socket-linger.obj From johan.tibell at gmail.com Mon Nov 30 11:23:05 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon Nov 30 10:58:14 2009 Subject: [network] new tickets submission unavailable In-Reply-To: References: Message-ID: <90889fe70911300823h11c575b5o38c2236db1e91268@mail.gmail.com> Hi Valery, On Mon, Nov 30, 2009 at 2:40 PM, Valery V. Vorotyntsev wrote: >> Example in the haddock documentation for `getAddrInfo' function is >> rendered incorrectly > > And what's the purpose of issue tracking system, which even _registered_ > user cannot create a ticket for? > > http://trac.haskell.org/network/wiki > > "What the bug?" I can create tickets here: http://trac.haskell.org/network/newticket As you can see by looking at the list of active tickets other people have also succeeded in creating tickets. What error are you seeing? Cheers, Johan From aslatter at gmail.com Mon Nov 30 11:39:22 2009 From: aslatter at gmail.com (Antoine Latter) Date: Mon Nov 30 11:14:11 2009 Subject: [network] new tickets submission unavailable In-Reply-To: <90889fe70911300823h11c575b5o38c2236db1e91268@mail.gmail.com> References: <90889fe70911300823h11c575b5o38c2236db1e91268@mail.gmail.com> Message-ID: <694519c50911300839v5725351cqfff1b6cecf820b98@mail.gmail.com> On Mon, Nov 30, 2009 at 10:23 AM, Johan Tibell wrote: > Hi Valery, > > On Mon, Nov 30, 2009 at 2:40 PM, Valery V. Vorotyntsev > wrote: >>> Example in the haddock documentation for `getAddrInfo' function is >>> rendered incorrectly >> >> And what's the purpose of issue tracking system, which even _registered_ >> user cannot create a ticket for? >> >> ? ?http://trac.haskell.org/network/wiki >> >> "What the bug?" > > I can create tickets here: > > http://trac.haskell.org/network/newticket > > As you can see by looking at the list of active tickets other people > have also succeeded in creating tickets. What error are you seeing? > My user (AntoineLatter) gets the following error when navigating to that URL: >>>>> Forbidden TICKET_CREATE privileges are required to perform this operation <<<<< Antoine From valery.vv at gmail.com Mon Nov 30 12:34:18 2009 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Mon Nov 30 12:09:10 2009 Subject: [network] new tickets submission unavailable In-Reply-To: <694519c50911300839v5725351cqfff1b6cecf820b98@mail.gmail.com> References: <90889fe70911300823h11c575b5o38c2236db1e91268@mail.gmail.com> <694519c50911300839v5725351cqfff1b6cecf820b98@mail.gmail.com> Message-ID: On Mon, Nov 30, 2009 at 6:39 PM, Antoine Latter wrote: > My user (AntoineLatter) gets the following error when navigating to that URL: > >>>>>> > Forbidden > > TICKET_CREATE privileges are required to perform this operation > <<<<< +1 -- vvv From ross at soi.city.ac.uk Mon Nov 30 18:50:27 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Nov 30 18:26:22 2009 Subject: MTL vs Transformers. Any status update? In-Reply-To: <7fb8f82f0911291629t4f225b46ufb214331c0f5decc@mail.gmail.com> References: <20091127081650.fd48e441.mle+hs@mega-nerd.com> <20091127003302.GA29911@soi.city.ac.uk> <1259426449.4896.74853.camel@localhost> <20091128165650.GA15637@soi.city.ac.uk> <1259499786.4896.79853.camel@localhost> <20091129133530.GA10045@soi.city.ac.uk> <1259521342.4896.81324.camel@localhost> <29bf512f0911291108o7404d83bg710bedca6189fbfe@mail.gmail.com> <1259524136.4896.81549.camel@localhost> <7fb8f82f0911291629t4f225b46ufb214331c0f5decc@mail.gmail.com> Message-ID: <20091130235027.GA2434@soi.city.ac.uk> On Sun, Nov 29, 2009 at 07:29:47PM -0500, Edward Kmett wrote: > The final issue is whether or not it is a good idea to eliminate the > simpler non-transformer versions of the monads. > > Without them, libraries that provide instances for the various monads > cannot provide instances for State and StateT in a way that lets them > work compatibly with both versions. > > So, an issue that I would like to talk about separately is if we > _should_ be dropping the basic State, Reader, Writer, etc. constructors. > They have definite pedagogical value, and have easier to understand > behavior for introductory purposes. If we kept those then ALL code > that worked with mtl 1.2 would be compatible with mtl 2, which strikes > me as a desirable property. This has the benefit that it is easier > to write libraries that export instances. I think we would be remiss > in not at least considering the issue. On the other hand, I don't > know how many libraries provide instances for the monads in the MTL. > I have a few in my monoids library, but I'd be willing to go either way. The benefit of defining these as type synonyms is that the Haskell 98 transformers package has the same functions operating on both the base monad and the corresponding transformer; there is no need to define two versions of everything. Similarly fewer instances are required in the monad class packages. I think the pedagogical issue can be handled in other ways, and that making compatibility with the current mtl an overriding requirement would be unduly constraining. In any case there would be no complete compatibility, as transformers adds Applicative and Alternative instances, and also changes the constraints on Functor instances. From ekmett at gmail.com Mon Nov 30 20:02:15 2009 From: ekmett at gmail.com (Edward Kmett) Date: Mon Nov 30 19:37:04 2009 Subject: MTL vs Transformers. Any status update? In-Reply-To: <20091130235027.GA2434@soi.city.ac.uk> References: <20091127081650.fd48e441.mle+hs@mega-nerd.com> <1259426449.4896.74853.camel@localhost> <20091128165650.GA15637@soi.city.ac.uk> <1259499786.4896.79853.camel@localhost> <20091129133530.GA10045@soi.city.ac.uk> <1259521342.4896.81324.camel@localhost> <29bf512f0911291108o7404d83bg710bedca6189fbfe@mail.gmail.com> <1259524136.4896.81549.camel@localhost> <7fb8f82f0911291629t4f225b46ufb214331c0f5decc@mail.gmail.com> <20091130235027.GA2434@soi.city.ac.uk> Message-ID: <7fb8f82f0911301702v362fe1eexec278d7ca426afa7@mail.gmail.com> On Mon, Nov 30, 2009 at 6:50 PM, Ross Paterson wrote: > On Sun, Nov 29, 2009 at 07:29:47PM -0500, Edward Kmett wrote: > > The final issue is whether or not it is a good idea to eliminate the > > simpler non-transformer versions of the monads. > > > > Without them, libraries that provide instances for the various monads > > cannot provide instances for State and StateT in a way that lets them > > work compatibly with both versions. > > > > So, an issue that I would like to talk about separately is if we > > _should_ be dropping the basic State, Reader, Writer, etc. constructors. > > They have definite pedagogical value, and have easier to understand > > behavior for introductory purposes. If we kept those then ALL code > > that worked with mtl 1.2 would be compatible with mtl 2, which strikes > > me as a desirable property. This has the benefit that it is easier > > to write libraries that export instances. I think we would be remiss > > in not at least considering the issue. On the other hand, I don't > > know how many libraries provide instances for the monads in the MTL. > > I have a few in my monoids library, but I'd be willing to go either way. > > The benefit of defining these as type synonyms is that the Haskell 98 > transformers package has the same functions operating on both the base > monad and the corresponding transformer; there is no need to define two > versions of everything. Similarly fewer instances are required in the > monad class packages. > True. Like I said, I'd be happy with either way. > I think the pedagogical issue can be handled in other ways, and that > making compatibility with the current mtl an overriding requirement > would be unduly constraining. In any case there would be no complete > compatibility, as transformers adds Applicative and Alternative instances, > and also changes the constraints on Functor instances. > I agree that perfect backwards compatibility is impossible. That said, unlike the type aliases, these are all cases where something new would work that didn't previously. Library code that wanted to be backwards compatible could avoid using the new instances, and the more permissive Functor instances shouldn't break any code that worked before unless that code was defining its own local version of Applicative, Alternative, etc. which were constrained by the restrictive Functor definitions to not work in the most permissive form anyway, so where needed, library code could work around using WrappedMonad, etc. in a way that would be compatible. It is true, that it would constrain the design of the mtl to carry a handful of handy (or burdensome, depending on your perspective) tutorial constructors around, but note that the functions themselves for working with the simpler type are still contained in transformers, so the function count doesn't really change either way. But the other way says that all of the libraries that re-export functionality on top of the mtl must discard coverage of the non-transformer case when linked against the old mtl. Both options suck, but only one provides no way out except to force someone up to the new version that they may not be able to use because of other package requirements. I have yet to see any major migration to a new version of a library that isn't more or less plug in compatible with the old version actually take hold (witness current adoption levels of parsec 3 & quickcheck 2). I hope this doesn't across as too cynical. I just figured that someone should play devil's advocate, before things got drowned in a sea of +1s. -Edward Kmett _______________________________________________ > 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/20091130/d04f0b3c/attachment.html