From ben at smart-cactus.org Thu Feb 2 18:18:54 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 02 Feb 2017 13:18:54 -0500 Subject: Selection Monad In-Reply-To: References: Message-ID: <874m0cihgx.fsf@ben-laptop.smart-cactus.org> Jakub Daniel writes: > Hi Eric, > > Just to clarify, my question was not about endorsing another library but > rather extending the ones currently maintained by the committee with > definition of a notion closely related to what is already contained in the > libraries. It just so happens that Edward Kmett implemented the notion in a > standalone library. However to me it does not make much sense to include > ContT but not SelT (currently under the name Search) in the core libraries, > despite their connection. I understand if this does not change the answer > though. > Admittedly the symmetry here is quite intriguing, data Sel r x = Sel {runSel :: (x → r) → x} data Cont r x = Cont {runCont :: (x → r) → r} In light of this I can see why one might say that including one yet not the other is odd. That being said, I'm not on the CLC so this is merely an idle observation. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From takenobu.hs at gmail.com Mon Feb 6 12:53:36 2017 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Mon, 6 Feb 2017 21:53:36 +0900 Subject: minor broken link in binary submodule Message-ID: Dear libraries, I'm reporting about minor broken link in source comment. There is a broken link in `libraries/binary/src/Data/Binary/Get.hs`. --- +-- Regards, Takenobu -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Tue Feb 7 00:07:50 2017 From: david.feuer at gmail.com (David Feuer) Date: Mon, 6 Feb 2017 19:07:50 -0500 Subject: Announcing containers 0.5.8.2, 0.5.9.2, and 0.5.10.1 Message-ID: I had not planned to make any additional releases before GHC 8.2, but bugs forced my hand. In particular, Tom Smalley discovered major bugs in Data.IntMap.restrictKeys and Data.IntMap.withoutKeys. A mistake I made adding those functions to the test suite prevented the problem from being discovered. This affects both 0.5.8.1 and 0.5.9.1, both of which are now deprecated. I believe both the functions and the test suite are now working as intended. In a less frightening bug fix, Ryan Scott fixed a discrepancy between the Show1 instance for Data.Tree and its Show instance. This affected version 0.5.9.1. I also fixed misdirected Haddock links in 0.5.9.1. Version 0.5.10.1 comes with one new feature: Data.Sequence has a MonadZip instance. Thanks also to Simon Jakobi for removing the meaningless stability annotations. David Feuer From ben at smart-cactus.org Thu Feb 9 19:16:06 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 09 Feb 2017 14:16:06 -0500 Subject: Proposal: Make minimumBy and maximumBy go through foldl1 In-Reply-To: References: Message-ID: <877f4zcgzt.fsf@ben-laptop.smart-cactus.org> David Laing writes: > Hi, > > Do the rest of the committee / folks on the list have any opinions either > way on whether the stopgap measure should go into the next release? I'm > fine either way, but my understanding is that more input is better when it > comes to proposals effecting `base`. > > I'll check back in two weeks from now and see if anyone has any additional > thoughts / opinions / comments. Can the committee give a thumbs up/down on this? The window for merging this to 8.2 is very nearly closed. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From david.feuer at gmail.com Thu Feb 9 20:20:16 2017 From: david.feuer at gmail.com (David Feuer) Date: Thu, 9 Feb 2017 15:20:16 -0500 Subject: Discussion: Implementation of fromList for Data.Set and Data.Map Message-ID: Currently, the implementations of fromList for Data.Set and Data.Map try to take advantage of inputs with some prefix in strictly increasing order. It uses the fast (O (n)) fromDistinctAscList algorithm for the strictly ascending prefix, and then falls back on the slower (O (n log n)) naive algorithm for the rest. For Data.Set, this works roughly like the implementation sketched at the bottom of this message. This whole thing strikes me as a bit odd: changing just the first element of the input list can have a substantial impact on the overall performance. In my opinion, there are two reasonable ways to implement this function: 1. Don't bother to try to take advantage of preexisting ordering. This is the simplest option, and will probably be fastest for lists with little preexisting order. 2. Try to take advantage of sorted ascending and descending "runs". A simple version would be to break up the input list into ascending and descending segments (merging duplicates on the fly), use fromDistinctAscList or fromDistinctDescList to convert each segment, and combine the segments using set unions. This option will be slower for totally unsorted lists, but should degrade much more gradually than the current algorithm as disorder is added. Wren suggests that there may be other variations on the same theme that we could consider. Should we A. Switch to 1 (and offer 2 by another name) B. Switch to 2 (and offer 1 by another name?) C. Leave fromList alone and offer 2 by another name Note that option 1 can be implemented quite easily outside the library using insert and foldl'; option 2 is not something users should be expected to write themselves. If we add names, what should those be? Thanks, David Feuer Current implementation sketch: fromList :: Ord a => [a] -> Set a fromList xs = foldl' (flip insert) sortedSet unsortedList where sortedSet = fromDistinctAscList sortedList (sortedList, unsortedList) = spanStrictlyAscending xs spanStrictlyAscending [] = ([], []) spanStrictlyAscending (x : xs) = x : go x xs where go prev (n : ns) | prev < n = first (n :) $ go n ns go _ ns = ([], ns) From ekmett at gmail.com Fri Feb 10 01:16:34 2017 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 9 Feb 2017 20:16:34 -0500 Subject: Discussion: Implementation of fromList for Data.Set and Data.Map In-Reply-To: References: Message-ID: The current implementation was really just an attempt to improve over the old implementation which did the naive construction. It did improve things for the sorted list case to the point where there is very little marginal benefit to using fromDistinctAscList any more, but it very much isn't the final word on the topic. =) Finding something that handles the middle cases where you have "mostly sorted" data better would be a good idea, but definitely needs to be benchmarked to death, and it would help to know if the merges of runs affect the overall asymptotic performance. Timsort is both fast and popular and includes a similar pass (it also happens to include handling strictly descending runs as mentioned), so it seems that there is room to do something similar here. -Edward On Thu, Feb 9, 2017 at 3:20 PM, David Feuer wrote: > Currently, the implementations of fromList for Data.Set and Data.Map > try to take advantage of inputs with some prefix in strictly > increasing order. It uses the fast (O (n)) fromDistinctAscList > algorithm for the strictly ascending prefix, and then falls back on > the slower (O (n log n)) naive algorithm for the rest. For Data.Set, > this works roughly like the implementation sketched at the bottom of > this message. > > This whole thing strikes me as a bit odd: changing just the first > element of the input list can have a substantial impact on the overall > performance. > > In my opinion, there are two reasonable ways to implement this function: > > 1. Don't bother to try to take advantage of preexisting ordering. This > is the simplest option, and will probably be fastest for lists with > little preexisting order. > > 2. Try to take advantage of sorted ascending and descending "runs". A > simple version would be to break up the input list into ascending and > descending segments (merging duplicates on the fly), use > fromDistinctAscList or fromDistinctDescList to convert each segment, > and combine the segments using set unions. This option will be slower > for totally unsorted lists, but should degrade much more gradually > than the current algorithm as disorder is added. Wren suggests that > there may be other variations on the same theme that we could > consider. > > Should we > > A. Switch to 1 (and offer 2 by another name) > B. Switch to 2 (and offer 1 by another name?) > C. Leave fromList alone and offer 2 by another name > > Note that option 1 can be implemented quite easily outside the library > using insert and foldl'; option 2 is not something users should be > expected to write themselves. > > If we add names, what should those be? > > Thanks, > David Feuer > > Current implementation sketch: > > fromList :: Ord a => [a] -> Set a > fromList xs = foldl' (flip insert) sortedSet unsortedList > where > sortedSet = fromDistinctAscList sortedList > (sortedList, unsortedList) = spanStrictlyAscending xs > > spanStrictlyAscending [] = ([], []) > spanStrictlyAscending (x : xs) = x : go x xs > where > go prev (n : ns) > | prev < n = first (n :) $ go n ns > go _ ns = ([], ns) > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Fri Feb 10 01:26:48 2017 From: david.feuer at gmail.com (David Feuer) Date: Thu, 9 Feb 2017 20:26:48 -0500 Subject: Discussion: Implementation of fromList for Data.Set and Data.Map In-Reply-To: References: Message-ID: Merging the sorted runs will not hurt big-O complexity. When I replaced the union algorithms, Ross Paterson noted that the time bounds on the new ones were good enough that starting from singletons we can take the unions in any order and build the set/map in O(n log n) time. My main concern is about constant factors. Like you said, I'll have to benchmark a lot. On Feb 9, 2017 8:16 PM, "Edward Kmett" wrote: > The current implementation was really just an attempt to improve over the > old implementation which did the naive construction. It did improve things > for the sorted list case to the point where there is very little marginal > benefit to using fromDistinctAscList any more, but it very much isn't the > final word on the topic. =) > > Finding something that handles the middle cases where you have "mostly > sorted" data better would be a good idea, but definitely needs to be > benchmarked to death, and it would help to know if the merges of runs > affect the overall asymptotic performance. > > Timsort is both fast and popular and includes a similar pass (it also > happens to include handling strictly descending runs as mentioned), so it > seems that there is room to do something similar here. > > -Edward > > On Thu, Feb 9, 2017 at 3:20 PM, David Feuer wrote: > >> Currently, the implementations of fromList for Data.Set and Data.Map >> try to take advantage of inputs with some prefix in strictly >> increasing order. It uses the fast (O (n)) fromDistinctAscList >> algorithm for the strictly ascending prefix, and then falls back on >> the slower (O (n log n)) naive algorithm for the rest. For Data.Set, >> this works roughly like the implementation sketched at the bottom of >> this message. >> >> This whole thing strikes me as a bit odd: changing just the first >> element of the input list can have a substantial impact on the overall >> performance. >> >> In my opinion, there are two reasonable ways to implement this function: >> >> 1. Don't bother to try to take advantage of preexisting ordering. This >> is the simplest option, and will probably be fastest for lists with >> little preexisting order. >> >> 2. Try to take advantage of sorted ascending and descending "runs". A >> simple version would be to break up the input list into ascending and >> descending segments (merging duplicates on the fly), use >> fromDistinctAscList or fromDistinctDescList to convert each segment, >> and combine the segments using set unions. This option will be slower >> for totally unsorted lists, but should degrade much more gradually >> than the current algorithm as disorder is added. Wren suggests that >> there may be other variations on the same theme that we could >> consider. >> >> Should we >> >> A. Switch to 1 (and offer 2 by another name) >> B. Switch to 2 (and offer 1 by another name?) >> C. Leave fromList alone and offer 2 by another name >> >> Note that option 1 can be implemented quite easily outside the library >> using insert and foldl'; option 2 is not something users should be >> expected to write themselves. >> >> If we add names, what should those be? >> >> Thanks, >> David Feuer >> >> Current implementation sketch: >> >> fromList :: Ord a => [a] -> Set a >> fromList xs = foldl' (flip insert) sortedSet unsortedList >> where >> sortedSet = fromDistinctAscList sortedList >> (sortedList, unsortedList) = spanStrictlyAscending xs >> >> spanStrictlyAscending [] = ([], []) >> spanStrictlyAscending (x : xs) = x : go x xs >> where >> go prev (n : ns) >> | prev < n = first (n :) $ go n ns >> go _ ns = ([], ns) >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From milan at strakovi.com Fri Feb 10 08:59:43 2017 From: milan at strakovi.com (Milan Straka) Date: Fri, 10 Feb 2017 09:59:43 +0100 Subject: Discussion: Implementation of fromList for Data.Set and Data.Map In-Reply-To: References: Message-ID: <20170210085943.GA14057@auryn.cz> Dear all, yes, as Edward says, the current implementation just alleviated the need to use fromDistinctAscList -- it was quite a common case of using fromList (because many functions produce sorted lists). Some adaptive algorithm depending on number of inversions (by inversion I mean $(x, y)$ such that $x$ preceeds $y$ and $x > y$), ideally with complexity $O(n \log (2+number_of_inversions/n))$, would definitely be desirable. I tried to experiment with it when I implemented this "use linear-time algorithm if sorted", but as noted in the e4e9a97 commit, I have no idea how to keep the constant factors small. Cheers, Milan Straka > -----Original message----- > From: David Feuer > Sent: 9 Feb 2017, 20:26 > > Merging the sorted runs will not hurt big-O complexity. When I replaced the > union algorithms, Ross Paterson noted that the time bounds on the new ones > were good enough that starting from singletons we can take the unions in > any order and build the set/map in O(n log n) time. My main concern is > about constant factors. Like you said, I'll have to benchmark a lot. > > On Feb 9, 2017 8:16 PM, "Edward Kmett" wrote: > > > The current implementation was really just an attempt to improve over the > > old implementation which did the naive construction. It did improve things > > for the sorted list case to the point where there is very little marginal > > benefit to using fromDistinctAscList any more, but it very much isn't the > > final word on the topic. =) > > > > Finding something that handles the middle cases where you have "mostly > > sorted" data better would be a good idea, but definitely needs to be > > benchmarked to death, and it would help to know if the merges of runs > > affect the overall asymptotic performance. > > > > Timsort is both fast and popular and includes a similar pass (it also > > happens to include handling strictly descending runs as mentioned), so it > > seems that there is room to do something similar here. > > > > -Edward > > > > On Thu, Feb 9, 2017 at 3:20 PM, David Feuer wrote: > > > >> Currently, the implementations of fromList for Data.Set and Data.Map > >> try to take advantage of inputs with some prefix in strictly > >> increasing order. It uses the fast (O (n)) fromDistinctAscList > >> algorithm for the strictly ascending prefix, and then falls back on > >> the slower (O (n log n)) naive algorithm for the rest. For Data.Set, > >> this works roughly like the implementation sketched at the bottom of > >> this message. > >> > >> This whole thing strikes me as a bit odd: changing just the first > >> element of the input list can have a substantial impact on the overall > >> performance. > >> > >> In my opinion, there are two reasonable ways to implement this function: > >> > >> 1. Don't bother to try to take advantage of preexisting ordering. This > >> is the simplest option, and will probably be fastest for lists with > >> little preexisting order. > >> > >> 2. Try to take advantage of sorted ascending and descending "runs". A > >> simple version would be to break up the input list into ascending and > >> descending segments (merging duplicates on the fly), use > >> fromDistinctAscList or fromDistinctDescList to convert each segment, > >> and combine the segments using set unions. This option will be slower > >> for totally unsorted lists, but should degrade much more gradually > >> than the current algorithm as disorder is added. Wren suggests that > >> there may be other variations on the same theme that we could > >> consider. > >> > >> Should we > >> > >> A. Switch to 1 (and offer 2 by another name) > >> B. Switch to 2 (and offer 1 by another name?) > >> C. Leave fromList alone and offer 2 by another name > >> > >> Note that option 1 can be implemented quite easily outside the library > >> using insert and foldl'; option 2 is not something users should be > >> expected to write themselves. > >> > >> If we add names, what should those be? > >> > >> Thanks, > >> David Feuer > >> > >> Current implementation sketch: > >> > >> fromList :: Ord a => [a] -> Set a > >> fromList xs = foldl' (flip insert) sortedSet unsortedList > >> where > >> sortedSet = fromDistinctAscList sortedList > >> (sortedList, unsortedList) = spanStrictlyAscending xs > >> > >> spanStrictlyAscending [] = ([], []) > >> spanStrictlyAscending (x : xs) = x : go x xs > >> where > >> go prev (n : ns) > >> | prev < n = first (n :) $ go n ns > >> go _ ns = ([], ns) > >> _______________________________________________ > >> Libraries mailing list > >> Libraries at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >> > > > > From david.feuer at gmail.com Sun Feb 12 04:56:36 2017 From: david.feuer at gmail.com (David Feuer) Date: Sat, 11 Feb 2017 23:56:36 -0500 Subject: Discussion: Implementation of fromList for Data.Set and Data.Map In-Reply-To: <20170210085943.GA14057@auryn.cz> References: <20170210085943.GA14057@auryn.cz> Message-ID: I tried about the simplest thing that could possibly work, and it doesn't seem terrible. As expected, it's pretty close to the current implementation for strictly increasing lists, and a good deal better for mostly-ordered lists (in either direction). Also as expected, it's worse for random inputs, but not as much worse as I feared: it takes about 26% longer. I suspect it's probably possible to do better. I tried to eliminate the intermediate lists, but unfortunately that seems to make it really messy to deal with merging duplicates. It may be worth doing anyway, or there may be some other optimization I haven't thought of. spanIncreasing :: Ord a => [a] -> ([a], [a]) spanIncreasing [] = ([], []) spanIncreasing (a : as) = first (a:) (go a as) where go _prev [] = ([], []) go prev q@(a : as) = case compare prev a of LT -> first (a :) $ go a as EQ -> go a as GT -> ([], q) spanDecreasing :: Ord a => [a] -> ([a], [a]) spanDecreasing [] = ([], []) spanDecreasing (a : as) = first (a:) (go a as) where go _prev [] = ([], []) go prev q@(a : as) = case compare prev a of GT -> first (a :) (go a as) EQ -> go a as LT -> ([], q) fromList :: Ord a => [a] -> Set a fromList = up empty where up !acc [] = acc up acc xs = case spanIncreasing xs of ([x], rest) -> down (insert x acc) rest (ups, rest) -> down (union (fromDistinctAscList ups) acc) rest down !acc [] = acc down acc xs = case spanDecreasing xs of ([x], rest) -> up (insert x acc) rest (downs, rest) -> up (union (fromDistinctDescList downs) acc) rest On Fri, Feb 10, 2017 at 3:59 AM, Milan Straka wrote: > Dear all, > > yes, as Edward says, the current implementation just alleviated the need > to use fromDistinctAscList -- it was quite a common case of using > fromList (because many functions produce sorted lists). > > Some adaptive algorithm depending on number of inversions (by inversion > I mean $(x, y)$ such that $x$ preceeds $y$ and $x > y$), ideally > with complexity $O(n \log (2+number_of_inversions/n))$, would definitely > be desirable. I tried to experiment with it when I implemented this > "use linear-time algorithm if sorted", but as noted in the e4e9a97 > commit, I have no idea how to keep the constant factors small. > > Cheers, > Milan Straka > >> -----Original message----- >> From: David Feuer >> Sent: 9 Feb 2017, 20:26 >> >> Merging the sorted runs will not hurt big-O complexity. When I replaced the >> union algorithms, Ross Paterson noted that the time bounds on the new ones >> were good enough that starting from singletons we can take the unions in >> any order and build the set/map in O(n log n) time. My main concern is >> about constant factors. Like you said, I'll have to benchmark a lot. >> >> On Feb 9, 2017 8:16 PM, "Edward Kmett" wrote: >> >> > The current implementation was really just an attempt to improve over the >> > old implementation which did the naive construction. It did improve things >> > for the sorted list case to the point where there is very little marginal >> > benefit to using fromDistinctAscList any more, but it very much isn't the >> > final word on the topic. =) >> > >> > Finding something that handles the middle cases where you have "mostly >> > sorted" data better would be a good idea, but definitely needs to be >> > benchmarked to death, and it would help to know if the merges of runs >> > affect the overall asymptotic performance. >> > >> > Timsort is both fast and popular and includes a similar pass (it also >> > happens to include handling strictly descending runs as mentioned), so it >> > seems that there is room to do something similar here. >> > >> > -Edward >> > >> > On Thu, Feb 9, 2017 at 3:20 PM, David Feuer wrote: >> > >> >> Currently, the implementations of fromList for Data.Set and Data.Map >> >> try to take advantage of inputs with some prefix in strictly >> >> increasing order. It uses the fast (O (n)) fromDistinctAscList >> >> algorithm for the strictly ascending prefix, and then falls back on >> >> the slower (O (n log n)) naive algorithm for the rest. For Data.Set, >> >> this works roughly like the implementation sketched at the bottom of >> >> this message. >> >> >> >> This whole thing strikes me as a bit odd: changing just the first >> >> element of the input list can have a substantial impact on the overall >> >> performance. >> >> >> >> In my opinion, there are two reasonable ways to implement this function: >> >> >> >> 1. Don't bother to try to take advantage of preexisting ordering. This >> >> is the simplest option, and will probably be fastest for lists with >> >> little preexisting order. >> >> >> >> 2. Try to take advantage of sorted ascending and descending "runs". A >> >> simple version would be to break up the input list into ascending and >> >> descending segments (merging duplicates on the fly), use >> >> fromDistinctAscList or fromDistinctDescList to convert each segment, >> >> and combine the segments using set unions. This option will be slower >> >> for totally unsorted lists, but should degrade much more gradually >> >> than the current algorithm as disorder is added. Wren suggests that >> >> there may be other variations on the same theme that we could >> >> consider. >> >> >> >> Should we >> >> >> >> A. Switch to 1 (and offer 2 by another name) >> >> B. Switch to 2 (and offer 1 by another name?) >> >> C. Leave fromList alone and offer 2 by another name >> >> >> >> Note that option 1 can be implemented quite easily outside the library >> >> using insert and foldl'; option 2 is not something users should be >> >> expected to write themselves. >> >> >> >> If we add names, what should those be? >> >> >> >> Thanks, >> >> David Feuer >> >> >> >> Current implementation sketch: >> >> >> >> fromList :: Ord a => [a] -> Set a >> >> fromList xs = foldl' (flip insert) sortedSet unsortedList >> >> where >> >> sortedSet = fromDistinctAscList sortedList >> >> (sortedList, unsortedList) = spanStrictlyAscending xs >> >> >> >> spanStrictlyAscending [] = ([], []) >> >> spanStrictlyAscending (x : xs) = x : go x xs >> >> where >> >> go prev (n : ns) >> >> | prev < n = first (n :) $ go n ns >> >> go _ ns = ([], ns) >> >> _______________________________________________ >> >> Libraries mailing list >> >> Libraries at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> >> > >> > From winterkoninkje at gmail.com Sun Feb 12 21:52:33 2017 From: winterkoninkje at gmail.com (wren romano) Date: Sun, 12 Feb 2017 13:52:33 -0800 Subject: Discussion: Implementation of fromList for Data.Set and Data.Map In-Reply-To: References: <20170210085943.GA14057@auryn.cz> Message-ID: On Sat, Feb 11, 2017 at 8:56 PM, David Feuer wrote: > spanIncreasing :: Ord a => [a] -> ([a], [a]) > spanIncreasing [] = ([], []) > spanIncreasing (a : as) = first (a:) (go a as) > where > go _prev [] = ([], []) > go prev q@(a : as) = case compare prev a of > LT -> first (a :) $ go a as > EQ -> go a as > GT -> ([], q) Suggest CPSing away the intermediate list: spanIncreasing :: Ord a => r -> (r -> a -> r) -> [a] -> (r, [a]) spanIncreasing z k [] = (z, []) spanIncreasing z k (x:xs) = go z k x xs case go !z k !x [] = (z, []) go z k x yys@(y:ys) | x < y = go (k z x) y ys | x == y = go z k x ys | otherwise = (k z x, yys) > spanDecreasing :: Ord a => [a] -> ([a], [a]) > spanDecreasing [] = ([], []) > spanDecreasing (a : as) = first (a:) (go a as) > where > go _prev [] = ([], []) > go prev q@(a : as) = case compare prev a of > GT -> first (a :) (go a as) > EQ -> go a as > LT -> ([], q) Ditto > fromList :: Ord a => [a] -> Set a > fromList = up empty > where > up !acc [] = acc > up acc xs = case spanIncreasing xs of > ([x], rest) -> down (insert x acc) rest > (ups, rest) -> down (union (fromDistinctAscList ups) acc) rest > > down !acc [] = acc > down acc xs = case spanDecreasing xs of > ([x], rest) -> up (insert x acc) rest > (downs, rest) -> up (union (fromDistinctDescList downs) acc) rest Here, I suggest inlining the above to dynamically choose whether to call `up` or `down`. E.g., something like (untested): fromList :: Ord a => [a] -> Set a fromList [] = empty fromList (x0:xs0) = start empty x0 xs0 where start !acc !x [] = insert x acc start acc x (y:ys) = case compare x y of LT -> up acc (singletonUp x) y ys EQ -> start acc x ys GT -> down acc (singletonDown x) y ys up !acc1 !acc2 !x [] = union acc1 (upSet (insertUp x acc2)) up acc1 acc2 x (y:ys) = case compare x y of LT -> up acc1 (insertUp x acc2) y ys EQ -> up acc1 acc2 x ys GT -> start (union acc1 (upSet (insertUp x acc2))) y ys down !acc1 !acc2 !x [] = union acc1 (downSet (insertDown x acc2)) down acc1 acc2 x (y:ys) = case compare x y of GT -> down acc1 (insertDown x acc2) y ys EQ -> down acc1 acc2 x ys LT -> start (union acc1 (downSet (insertDown x acc2))) y ys where `insertUp` and `insertDown` are the incremental steps of fromAscList/fromDescList, and `acc2` has whatever appropriate intermediate type it needs for that to work, and upSet/downSet does the conversion from that intermediate type into a standard Set. A naive but workable intermediate type gives us: singletonUp = (:[]) singletonDown = (:[]) insertUp = (:) insertDown = (:) upSet = fromAscList downSet = fromDescList Though we should be able to do better than that. -- Live well, ~wren From mike at barrucadu.co.uk Wed Feb 15 23:31:17 2017 From: mike at barrucadu.co.uk (Michael Walker) Date: Wed, 15 Feb 2017 23:31:17 +0000 Subject: Proposal: Add a Void1 :: * -> * type to base Message-ID: <20170215233117.26f5182e@azathoth> Hi, Recently I found myself in need of a type like Void, but taking a type parameter, so I wrote up a fairly simple implementation inspired by Data.Void: {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE EmptyCase #-} {-# LANGUAGE StandaloneDeriving #-} data Void1 a deriving Generic deriving instance Data a => Data (Void1 a) instance Ix (Void1 a) where range _ = [] index _ = absurd1 inRange _ = absurd1 rangeSize _ = 0 instance Typeable a => Exception (Void1 a) instance Eq (Void1 a) where _ == _ = True instance Ord (Void1 a) where compare _ _ = EQ instance Read (Void1 a) where readsPrec _ _ = [] instance Semigroup (Void1 a) where a <> _ = a instance Show (Void1 a) where show = absurd1 instance Functor Void1 where fmap _ = absurd1 instance Foldable Void1 where foldMap _ = absurd1 instance Traversable Void1 where traverse _ = absurd1 absurd1 :: Void1 a -> b absurd1 v = case v of {} (If we step outside the realm of base, this type is also a Contravariant and a Comonad) I left this sitting alone in a Utils module until last night when I saw someone ask in #haskell if there was "a Void1 type defined in some central place". So, in case this is of more general interest, I propose that a module Data.Functor.Void be added to base. Another colour to paint this bikeshed would be "VoidF", rather than "Void1". Also, this could be added to Data.Void rather than be a new module, but I think it's more sensible to include in the Data.Functor hierarchy, perhaps with a re-export from Data.Void. Discussion period: 2 weeks (ending Wed, 1st March) -- Michael Walker (http://www.barrucadu.co.uk) From bos at serpentine.com Wed Feb 15 23:54:44 2017 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed, 15 Feb 2017 15:54:44 -0800 Subject: Proposal: Add a Void1 :: * -> * type to base In-Reply-To: <20170215233117.26f5182e@azathoth> References: <20170215233117.26f5182e@azathoth> Message-ID: On Wed, Feb 15, 2017 at 3:31 PM, Michael Walker wrote: > I left this sitting alone in a Utils module until last night when I saw > someone ask in #haskell if there was "a Void1 type defined in some > central place". So, in case this is of more general interest, I propose > that a module Data.Functor.Void be added to base. > I think the bar for adding things to base is higher than "two people found it useful"... -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Wed Feb 15 23:58:43 2017 From: david.feuer at gmail.com (David Feuer) Date: Wed, 15 Feb 2017 18:58:43 -0500 Subject: Proposal: Add a Void1 :: * -> * type to base In-Reply-To: References: <20170215233117.26f5182e@azathoth> Message-ID: I think there was some discussion of this recently. We already have V1 in GHC.Generics; perhaps that could be given a better name. On Feb 15, 2017 6:55 PM, "Bryan O'Sullivan" wrote: > > On Wed, Feb 15, 2017 at 3:31 PM, Michael Walker > wrote: > >> I left this sitting alone in a Utils module until last night when I saw >> someone ask in #haskell if there was "a Void1 type defined in some >> central place". So, in case this is of more general interest, I propose >> that a module Data.Functor.Void be added to base. >> > > I think the bar for adding things to base is higher than "two people found > it useful"... > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g9ks157k at acme.softbase.org Fri Feb 17 14:45:22 2017 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Fri, 17 Feb 2017 16:45:22 +0200 Subject: What top-level names are =?UTF-8?Q?=E2=80=9Callocated=E2=80=9D=3F?= Message-ID: <1487342722.26586.1.camel@acme.softbase.org> Hi! When uploading a new version of grapefruit-frp yesterday, I got the following warning from cabal-install: > Exposed modules use unallocated top-level names: FRP This made me wonder which top-level names are actually “allocated”. I tried to find this out from the Cabal sources, but the GitHub search functionality revealed no occurrences of the word “unallocated”. Regarding my concrete case, I think it would be good to change “FRP” to “Reactive”, which is what Reactive Banana is using, for example. However, is “Reactive” an “allocated” top-level name? All the best, Wolfgang From lemming at henning-thielemann.de Fri Feb 17 14:52:47 2017 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 17 Feb 2017 15:52:47 +0100 (CET) Subject: =?UTF-8?Q?Re=3A_What_top-level_names_are_=E2=80=9Callocated=E2=80=9D=3F?= In-Reply-To: <1487342722.26586.1.camel@acme.softbase.org> References: <1487342722.26586.1.camel@acme.softbase.org> Message-ID: On Fri, 17 Feb 2017, Wolfgang Jeltsch wrote: > Hi! > > When uploading a new version of grapefruit-frp yesterday, I got the > following warning from cabal-install: > >>  Exposed modules use unallocated top-level names: FRP > > This made me wonder which top-level names are actually “allocated”. > I tried to find this out from the Cabal sources, but the GitHub search > functionality revealed no occurrences of the word “unallocated”. It seems to be an answer from the server: https://github.com/haskell/hackage-server/blob/master/Distribution/Server/Packages/Unpack.hs allocatedTopLevelNodes lists allocated top-level names. From amindfv at gmail.com Fri Feb 17 16:14:35 2017 From: amindfv at gmail.com (amindfv at gmail.com) Date: Fri, 17 Feb 2017 10:14:35 -0600 Subject: =?utf-8?Q?Re:_What_top-level_names_are_=E2=80=9Callocated?= =?utf-8?Q?=E2=80=9D=3F?= In-Reply-To: <1487342722.26586.1.camel@acme.softbase.org> References: <1487342722.26586.1.camel@acme.softbase.org> Message-ID: "FRP" seems like something we could make an allocated name. Tom > El 17 feb 2017, a las 08:45, Wolfgang Jeltsch escribió: > > Hi! > > When uploading a new version of grapefruit-frp yesterday, I got the > following warning from cabal-install: > >> Exposed modules use unallocated top-level names: FRP > > This made me wonder which top-level names are actually “allocated”. > I tried to find this out from the Cabal sources, but the GitHub search > functionality revealed no occurrences of the word “unallocated”. > > Regarding my concrete case, I think it would be good to change “FRP” to > “Reactive”, which is what Reactive Banana is using, for example. > However, is “Reactive” an “allocated” top-level name? > > All the best, > Wolfgang > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From g9ks157k at acme.softbase.org Fri Feb 17 15:27:55 2017 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Fri, 17 Feb 2017 17:27:55 +0200 Subject: What top-level names are =?UTF-8?Q?=E2=80=9Callocated=E2=80=9D=3F?= In-Reply-To: References: <1487342722.26586.1.camel@acme.softbase.org> Message-ID: <1487345275.26586.4.camel@acme.softbase.org> I think, “Reactive” would be much better. Most modules about reactivity are FRP libraries anyhow. If we would have “FRP” as a top-level name, where would the few non-functional reactive libraries fit into? As I said, I plan to move from “FRP” to “Reactive” for Grapefruit anyhow. All the best, Wolfgang Am Freitag, den 17.02.2017, 10:14 -0600 schrieb amindfv at gmail.com: > "FRP" seems like something we could make an allocated name. > > Tom > > > > > > El 17 feb 2017, a las 08:45, Wolfgang Jeltsch > e.org> escribió: > > > > Hi! > > > > When uploading a new version of grapefruit-frp yesterday, I got the > > following warning from cabal-install: > > > > > > > >  Exposed modules use unallocated top-level names: FRP > > > > This made me wonder which top-level names are actually “allocated”. > > I tried to find this out from the Cabal sources, but the GitHub > > search functionality revealed no occurrences of the word > > “unallocated”. > > > > Regarding my concrete case, I think it would be good to change “FRP” > > to “Reactive”, which is what Reactive Banana is using, for example. > > However, is “Reactive” an “allocated” top-level name? > > > > All the best, > > Wolfgang From vagarenko at gmail.com Fri Feb 17 16:00:13 2017 From: vagarenko at gmail.com (Alexey Vagarenko) Date: Fri, 17 Feb 2017 21:00:13 +0500 Subject: =?UTF-8?B?UmU6IFdoYXQgdG9wLWxldmVsIG5hbWVzIGFyZSDigJxhbGxvY2F0ZWTigJ0/?= In-Reply-To: <1487345275.26586.4.camel@acme.softbase.org> References: <1487342722.26586.1.camel@acme.softbase.org> <1487345275.26586.4.camel@acme.softbase.org> Message-ID: Forgive me, but what does "allocated top-level name" mean? 2017-02-17 20:27 GMT+05:00 Wolfgang Jeltsch : > I think, “Reactive” would be much better. Most modules about reactivity > are FRP libraries anyhow. If we would have “FRP” as a top-level name, > where would the few non-functional reactive libraries fit into? As I > said, I plan to move from “FRP” to “Reactive” for Grapefruit anyhow. > > All the best, > Wolfgang > > Am Freitag, den 17.02.2017, 10:14 -0600 schrieb amindfv at gmail.com: > > "FRP" seems like something we could make an allocated name. > > > > Tom > > > > > > > > > > El 17 feb 2017, a las 08:45, Wolfgang Jeltsch > > e.org> escribió: > > > > > > Hi! > > > > > > When uploading a new version of grapefruit-frp yesterday, I got the > > > following warning from cabal-install: > > > > > > > > > > > Exposed modules use unallocated top-level names: FRP > > > > > > This made me wonder which top-level names are actually “allocated”. > > > I tried to find this out from the Cabal sources, but the GitHub > > > search functionality revealed no occurrences of the word > > > “unallocated”. > > > > > > Regarding my concrete case, I think it would be good to change “FRP” > > > to “Reactive”, which is what Reactive Banana is using, for example. > > > However, is “Reactive” an “allocated” top-level name? > > > > > > All the best, > > > Wolfgang > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at bergmark.nl Fri Feb 17 19:06:05 2017 From: adam at bergmark.nl (Adam Bergmark) Date: Fri, 17 Feb 2017 19:06:05 +0000 Subject: =?UTF-8?B?UmU6IFdoYXQgdG9wLWxldmVsIG5hbWVzIGFyZSDigJxhbGxvY2F0ZWTigJ0/?= In-Reply-To: References: <1487342722.26586.1.camel@acme.softbase.org> <1487345275.26586.4.camel@acme.softbase.org> Message-ID: The only thing it means afaik is that this warning triggers. Several projects ignore this and use a top level name instead. My vote would be to remove this warning. On Fri, 17 Feb 2017 at 17:01, Alexey Vagarenko wrote: Forgive me, but what does "allocated top-level name" mean? 2017-02-17 20:27 GMT+05:00 Wolfgang Jeltsch : I think, “Reactive” would be much better. Most modules about reactivity are FRP libraries anyhow. If we would have “FRP” as a top-level name, where would the few non-functional reactive libraries fit into? As I said, I plan to move from “FRP” to “Reactive” for Grapefruit anyhow. All the best, Wolfgang Am Freitag, den 17.02.2017, 10:14 -0600 schrieb amindfv at gmail.com: > "FRP" seems like something we could make an allocated name. > > Tom > > > > > > El 17 feb 2017, a las 08:45, Wolfgang Jeltsch > e.org> escribió: > > > > Hi! > > > > When uploading a new version of grapefruit-frp yesterday, I got the > > following warning from cabal-install: > > > > > > > > Exposed modules use unallocated top-level names: FRP > > > > This made me wonder which top-level names are actually “allocated”. > > I tried to find this out from the Cabal sources, but the GitHub > > search functionality revealed no occurrences of the word > > “unallocated”. > > > > Regarding my concrete case, I think it would be good to change “FRP” > > to “Reactive”, which is what Reactive Banana is using, for example. > > However, is “Reactive” an “allocated” top-level name? > > > > All the best, > > Wolfgang _______________________________________________ Libraries mailing list Libraries at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries _______________________________________________ Libraries mailing list Libraries at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From siddhanathan+eml at gmail.com Sat Feb 18 04:40:00 2017 From: siddhanathan+eml at gmail.com (Siddhanathan Shanmugam) Date: Fri, 17 Feb 2017 20:40:00 -0800 Subject: Proposal: flipped fmap in base (again) Message-ID: This was proposed about 7 years ago, and rejected at the time: https://ghc.haskell.org/trac/ghc/ticket/3962 Is it okay if I revive this argument now? I think it would be useful to have the lens operator <&> in base, which is defined as: (<&>) :: Functor f => f a -> (a -> b) -> f b as <&> f = f <$> as This is analogous to a lifted version of (&) that already present in Data.Function Cheers, Sid -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.dijk.bas at gmail.com Sat Feb 18 09:09:22 2017 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Sat, 18 Feb 2017 10:09:22 +0100 Subject: Proposal: flipped fmap in base (again) In-Reply-To: References: Message-ID: I'm still in favour of this so a +1 from me. For completeness, your proposal should also specify from which module this will be exported and what the fixity and precedence will be. Bas Op 18 feb. 2017 05:41 schreef "Siddhanathan Shanmugam" < siddhanathan+eml at gmail.com>: This was proposed about 7 years ago, and rejected at the time: https://ghc.haskell.org/trac/ghc/ticket/3962 Is it okay if I revive this argument now? I think it would be useful to have the lens operator <&> in base, which is defined as: (<&>) :: Functor f => f a -> (a -> b) -> f b as <&> f = f <$> as This is analogous to a lifted version of (&) that already present in Data.Function Cheers, Sid _______________________________________________ Libraries mailing list Libraries at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Sat Feb 18 09:47:04 2017 From: fa-ml at ariis.it (Francesco Ariis) Date: Sat, 18 Feb 2017 10:47:04 +0100 Subject: Proposal: flipped fmap in base (again) In-Reply-To: References: Message-ID: <20170218094704.GA2824@casa.casa> On Fri, Feb 17, 2017 at 08:40:00PM -0800, Siddhanathan Shanmugam wrote: > This was proposed about 7 years ago, and rejected at the time: > https://ghc.haskell.org/trac/ghc/ticket/3962 >From that ticket > I'm not in favor of this proposal. Naming trivial compositions puts > a complexity tax on all users of the library and we end up with 2*n > operators instead of n operators and one flip function. It's trivial > to define the function locally or in a helper module. > > To elaborate: At work some of our core APIs have gotten dramatically > more complex due to their maintainers allowing people, in interest to > keep their own code cleaner, to add small helper functions to those > APIs. This is now recognized as bad practice and discouraged with a > call to "not fear the semicolon"! (We use mostly imperative languages > at work.) (by Johan Tibell) Those arguments seems to me as compelling today as they were 7 years ago, what has changed meanwhile? From johnw at newartisans.com Sat Feb 18 11:01:02 2017 From: johnw at newartisans.com (John Wiegley) Date: Sat, 18 Feb 2017 03:01:02 -0800 Subject: Proposal: flipped fmap in base (again) In-Reply-To: (Bas van Dijk's message of "Sat, 18 Feb 2017 10:09:22 +0100") References: Message-ID: >>>>> "BvD" == Bas van Dijk writes: BvD> I'm still in favour of this so a +1 from me. +1 from me too. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 From abela at chalmers.se Sat Feb 18 12:22:30 2017 From: abela at chalmers.se (Andreas Abel) Date: Sat, 18 Feb 2017 13:22:30 +0100 Subject: Proposal: flipped fmap in base (again) In-Reply-To: References: Message-ID: <780ef62b-b26b-840d-9013-3d6373e22d58@chalmers.se> +1 from me. --Andreas On 18.02.2017 12:01, John Wiegley wrote: >>>>>> "BvD" == Bas van Dijk writes: > > BvD> I'm still in favour of this so a +1 from me. > > +1 from me too. > -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www.cse.chalmers.se/~abela/ From siddhanathan+eml at gmail.com Sat Feb 18 17:28:44 2017 From: siddhanathan+eml at gmail.com (Siddhanathan Shanmugam) Date: Sat, 18 Feb 2017 09:28:44 -0800 Subject: Proposal: flipped fmap in base (again) In-Reply-To: <780ef62b-b26b-840d-9013-3d6373e22d58@chalmers.se> References: <780ef62b-b26b-840d-9013-3d6373e22d58@chalmers.se> Message-ID: > For completeness, your proposal should also specify from which > module this will be exported and what the fixity and precedence will be. module Data.Functor, infixl 1, and should not be in prelude. > Those arguments seems to me as compelling today as they were 7 > years ago, what has changed meanwhile? The addition of (&) in base: https://mail.haskell.org/pipermail/libraries/2013-October/021423.html -- Sid On Sat, Feb 18, 2017 at 4:22 AM, Andreas Abel wrote: > +1 from me. --Andreas > > On 18.02.2017 12:01, John Wiegley wrote: > >> "BvD" == Bas van Dijk writes: >>>>>>> >>>>>> >> BvD> I'm still in favour of this so a +1 from me. >> >> +1 from me too. >> >> > > -- > Andreas Abel <>< Du bist der geliebte Mensch. > > Department of Computer Science and Engineering > Chalmers and Gothenburg University, Sweden > > andreas.abel at gu.se > http://www.cse.chalmers.se/~abela/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Sat Feb 18 20:23:46 2017 From: ekmett at gmail.com (Edward Kmett) Date: Sat, 18 Feb 2017 15:23:46 -0500 Subject: Proposal: flipped fmap in base (again) In-Reply-To: References: <780ef62b-b26b-840d-9013-3d6373e22d58@chalmers.se> Message-ID: I'm weakly +1 on this proposal. In my experience foo <&> \x -> ... works out as a nice idiom because it avoids having to parenthesize the lambda unlike the usual <$> convention. For me, I can just make lens re-export the Data.Functor version on newer GHCs. -Edward On Sat, Feb 18, 2017 at 12:28 PM, Siddhanathan Shanmugam < siddhanathan+eml at gmail.com> wrote: > > For completeness, your proposal should also specify from which > > module this will be exported and what the fixity and precedence will be. > > module Data.Functor, infixl 1, and should not be in prelude. > > > Those arguments seems to me as compelling today as they were 7 > > years ago, what has changed meanwhile? > > The addition of (&) in base: https://mail.haskell. > org/pipermail/libraries/2013-October/021423.html > > > -- Sid > > > On Sat, Feb 18, 2017 at 4:22 AM, Andreas Abel wrote: > >> +1 from me. --Andreas >> >> On 18.02.2017 12:01, John Wiegley wrote: >> >>> "BvD" == Bas van Dijk writes: >>>>>>>> >>>>>>> >>> BvD> I'm still in favour of this so a +1 from me. >>> >>> +1 from me too. >>> >>> >> >> -- >> Andreas Abel <>< Du bist der geliebte Mensch. >> >> Department of Computer Science and Engineering >> Chalmers and Gothenburg University, Sweden >> >> andreas.abel at gu.se >> http://www.cse.chalmers.se/~abela/ >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eacameron at gmail.com Sun Feb 19 22:52:32 2017 From: eacameron at gmail.com (Elliot Cameron) Date: Sun, 19 Feb 2017 17:52:32 -0500 Subject: Proposal: flipped fmap in base (again) In-Reply-To: References: <780ef62b-b26b-840d-9013-3d6373e22d58@chalmers.se> Message-ID: Could we instead have "ffor" which can be used prefix or infix and avoids the operator soup problem? On Feb 18, 2017 3:24 PM, "Edward Kmett" wrote: > I'm weakly +1 on this proposal. In my experience > > foo <&> \x -> ... > > works out as a nice idiom because it avoids having to parenthesize the > lambda unlike the usual <$> convention. > > For me, I can just make lens re-export the Data.Functor version on newer > GHCs. > > -Edward > > On Sat, Feb 18, 2017 at 12:28 PM, Siddhanathan Shanmugam < > siddhanathan+eml at gmail.com> wrote: > >> > For completeness, your proposal should also specify from which >> > module this will be exported and what the fixity and precedence will be. >> >> module Data.Functor, infixl 1, and should not be in prelude. >> >> > Those arguments seems to me as compelling today as they were 7 >> > years ago, what has changed meanwhile? >> >> The addition of (&) in base: https://mail.haskell.org >> /pipermail/libraries/2013-October/021423.html >> >> >> -- Sid >> >> >> On Sat, Feb 18, 2017 at 4:22 AM, Andreas Abel wrote: >> >>> +1 from me. --Andreas >>> >>> On 18.02.2017 12:01, John Wiegley wrote: >>> >>>> "BvD" == Bas van Dijk writes: >>>>>>>>> >>>>>>>> >>>> BvD> I'm still in favour of this so a +1 from me. >>>> >>>> +1 from me too. >>>> >>>> >>> >>> -- >>> Andreas Abel <>< Du bist der geliebte Mensch. >>> >>> Department of Computer Science and Engineering >>> Chalmers and Gothenburg University, Sweden >>> >>> andreas.abel at gu.se >>> http://www.cse.chalmers.se/~abela/ >>> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abela at chalmers.se Mon Feb 20 08:42:34 2017 From: abela at chalmers.se (Andreas Abel) Date: Mon, 20 Feb 2017 09:42:34 +0100 Subject: Proposal: flipped fmap in base (again) In-Reply-To: References: <780ef62b-b26b-840d-9013-3d6373e22d58@chalmers.se> Message-ID: <07a950cd-3716-3861-e29d-c9ff83b28257@chalmers.se> I am using `for` https://hackage.haskell.org/package/Agda-2.5.2/docs/Agda-Utils-Functor.html and I think taking `for` for Applicative was name theft. On 19.02.2017 23:52, Elliot Cameron wrote: > Could we instead have "ffor" which can be used prefix or infix and > avoids the operator soup problem? > > On Feb 18, 2017 3:24 PM, "Edward Kmett" > wrote: > > I'm weakly +1 on this proposal. In my experience > > foo <&> \x -> ... > > works out as a nice idiom because it avoids having to parenthesize > the lambda unlike the usual <$> convention. > > For me, I can just make lens re-export the Data.Functor version on > newer GHCs. > > -Edward > > On Sat, Feb 18, 2017 at 12:28 PM, Siddhanathan Shanmugam > > wrote: > > > For completeness, your proposal should also specify from which > > module this will be exported and what the fixity and precedence will be. > > module Data.Functor, infixl 1, and should not be in prelude. > > > Those arguments seems to me as compelling today as they were 7 > > years ago, what has changed meanwhile? > > The addition of (&) in > base: https://mail.haskell.org/pipermail/libraries/2013-October/021423.html > > > > -- Sid > > > On Sat, Feb 18, 2017 at 4:22 AM, Andreas Abel > wrote: > > +1 from me. --Andreas > > On 18.02.2017 12:01, John Wiegley wrote: > > "BvD" == Bas van Dijk > > writes: > > > BvD> I'm still in favour of this so a +1 from me. > > +1 from me too. > > > > -- > Andreas Abel <>< Du bist der geliebte Mensch. > > Department of Computer Science and Engineering > Chalmers and Gothenburg University, Sweden > > andreas.abel at gu.se > http://www.cse.chalmers.se/~abela/ > > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www.cse.chalmers.se/~abela/ From ekmett at gmail.com Mon Feb 20 13:56:57 2017 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 20 Feb 2017 08:56:57 -0500 Subject: Proposal: flipped fmap in base (again) In-Reply-To: <07a950cd-3716-3861-e29d-c9ff83b28257@chalmers.se> References: <780ef62b-b26b-840d-9013-3d6373e22d58@chalmers.se> <07a950cd-3716-3861-e29d-c9ff83b28257@chalmers.se> Message-ID: On Mon, Feb 20, 2017 at 3:42 AM, Andreas Abel wrote: > I am using `for` > > https://hackage.haskell.org/package/Agda-2.5.2/docs/Agda-Uti > ls-Functor.html > > and I think taking `for` for Applicative was name theft. This crime may no longer be charged under the statute of limitations. The federal code provides that no person can be tried or punished for any noncapital offense unless they are indicted or information is instituted within five years of the date the offense was committed. Of course, that is here within the U.S. You might have better luck in the international court of public opinion. =) -Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon Feb 20 22:20:09 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 20 Feb 2017 17:20:09 -0500 Subject: Proposal: Add splitL and splitR to =?UTF-8?Q?container=E2=80=99s?= Map APIs In-Reply-To: <1485891888.1237.3.camel@joachim-breitner.de> References: <1485891888.1237.3.camel@joachim-breitner.de> Message-ID: <1487629209.1086.13.camel@joachim-breitner.de> Hi, Am Dienstag, den 31.01.2017, 14:44 -0500 schrieb Joachim Breitner: > splitL :: Ord k => k -> Map k a -> (Map k a, Map k a) > splitR :: Ord k => k -> Map k a -> (Map k a, Map k a) > > Corresponding issue: https://github.com/haskell/containers/issues/387 > Discussion period:   2 weeks (until Feb 14). the discussion showed the existence of spanAntitone, which is better, and no further interest was raised in this. I therefore conclude the discussion period with “no, we ain’t gonna take it” Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From joehillen at gmail.com Wed Feb 22 09:16:00 2017 From: joehillen at gmail.com (Joe Hillenbrand) Date: Wed, 22 Feb 2017 01:16:00 -0800 Subject: Proposal: flipped fmap in base (again) In-Reply-To: References: <780ef62b-b26b-840d-9013-3d6373e22d58@chalmers.se> <07a950cd-3716-3861-e29d-c9ff83b28257@chalmers.se> Message-ID: +1 Please, please, please can we have this? > Could we instead have "ffor" which can be used prefix or infix and avoids the operator soup problem? -1 On Mon, Feb 20, 2017 at 5:56 AM, Edward Kmett wrote: > On Mon, Feb 20, 2017 at 3:42 AM, Andreas Abel wrote: >> >> I am using `for` >> >> >> https://hackage.haskell.org/package/Agda-2.5.2/docs/Agda-Utils-Functor.html >> >> and I think taking `for` for Applicative was name theft. > > > This crime may no longer be charged under the statute of limitations. The > federal code provides that no person can be tried or punished for any > noncapital offense unless they are indicted or information is instituted > within five years of the date the offense was committed. > > Of course, that is here within the U.S. You might have better luck in the > international court of public opinion. =) > > -Edward > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > From eacameron at gmail.com Wed Feb 22 18:58:43 2017 From: eacameron at gmail.com (Elliot Cameron) Date: Wed, 22 Feb 2017 13:58:43 -0500 Subject: Proposal: flipped fmap in base (again) In-Reply-To: References: <780ef62b-b26b-840d-9013-3d6373e22d58@chalmers.se> <07a950cd-3716-3861-e29d-c9ff83b28257@chalmers.se> Message-ID: For the record, it makes no sense to me to have (<&>) *without* ffor. I am personally ambivalent about (<&>) in base, but I'd be -1 if it were not accompanied by ffor. On Wed, Feb 22, 2017 at 4:16 AM, Joe Hillenbrand wrote: > +1 Please, please, please can we have this? > > > Could we instead have "ffor" which can be used prefix or infix and > avoids the operator soup problem? > > -1 > > On Mon, Feb 20, 2017 at 5:56 AM, Edward Kmett wrote: > > On Mon, Feb 20, 2017 at 3:42 AM, Andreas Abel wrote: > >> > >> I am using `for` > >> > >> > >> https://hackage.haskell.org/package/Agda-2.5.2/docs/Agda- > Utils-Functor.html > >> > >> and I think taking `for` for Applicative was name theft. > > > > > > This crime may no longer be charged under the statute of limitations. The > > federal code provides that no person can be tried or punished for any > > noncapital offense unless they are indicted or information is instituted > > within five years of the date the offense was committed. > > > > Of course, that is here within the U.S. You might have better luck in the > > international court of public opinion. =) > > > > -Edward > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Wed Feb 22 19:37:36 2017 From: david.feuer at gmail.com (David Feuer) Date: Wed, 22 Feb 2017 14:37:36 -0500 Subject: Proposal: flipped fmap in base (again) In-Reply-To: References: <780ef62b-b26b-840d-9013-3d6373e22d58@chalmers.se> <07a950cd-3716-3861-e29d-c9ff83b28257@chalmers.se> Message-ID: I'm very much against the name ffor. Wouldn't forF be a better fit? On Wed, Feb 22, 2017 at 1:58 PM, Elliot Cameron wrote: > For the record, it makes no sense to me to have (<&>) without ffor. I am > personally ambivalent about (<&>) in base, but I'd be -1 if it were not > accompanied by ffor. > > On Wed, Feb 22, 2017 at 4:16 AM, Joe Hillenbrand > wrote: >> >> +1 Please, please, please can we have this? >> >> > Could we instead have "ffor" which can be used prefix or infix and >> > avoids the operator soup problem? >> >> -1 >> >> On Mon, Feb 20, 2017 at 5:56 AM, Edward Kmett wrote: >> > On Mon, Feb 20, 2017 at 3:42 AM, Andreas Abel wrote: >> >> >> >> I am using `for` >> >> >> >> >> >> >> >> https://hackage.haskell.org/package/Agda-2.5.2/docs/Agda-Utils-Functor.html >> >> >> >> and I think taking `for` for Applicative was name theft. >> > >> > >> > This crime may no longer be charged under the statute of limitations. >> > The >> > federal code provides that no person can be tried or punished for any >> > noncapital offense unless they are indicted or information is instituted >> > within five years of the date the offense was committed. >> > >> > Of course, that is here within the U.S. You might have better luck in >> > the >> > international court of public opinion. =) >> > >> > -Edward >> > >> > _______________________________________________ >> > Libraries mailing list >> > Libraries at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > From eacameron at gmail.com Wed Feb 22 20:11:59 2017 From: eacameron at gmail.com (Elliot Cameron) Date: Wed, 22 Feb 2017 15:11:59 -0500 Subject: Proposal: flipped fmap in base (again) In-Reply-To: References: <780ef62b-b26b-840d-9013-3d6373e22d58@chalmers.se> <07a950cd-3716-3861-e29d-c9ff83b28257@chalmers.se> Message-ID: FWIW, I'm less concerned about the precise name of ffor, although it seems sad to to lose the obvious correlation with fmap. On Wed, Feb 22, 2017 at 2:37 PM, David Feuer wrote: > I'm very much against the name ffor. Wouldn't forF be a better fit? > > On Wed, Feb 22, 2017 at 1:58 PM, Elliot Cameron > wrote: > > For the record, it makes no sense to me to have (<&>) without ffor. I am > > personally ambivalent about (<&>) in base, but I'd be -1 if it were not > > accompanied by ffor. > > > > On Wed, Feb 22, 2017 at 4:16 AM, Joe Hillenbrand > > wrote: > >> > >> +1 Please, please, please can we have this? > >> > >> > Could we instead have "ffor" which can be used prefix or infix and > >> > avoids the operator soup problem? > >> > >> -1 > >> > >> On Mon, Feb 20, 2017 at 5:56 AM, Edward Kmett wrote: > >> > On Mon, Feb 20, 2017 at 3:42 AM, Andreas Abel > wrote: > >> >> > >> >> I am using `for` > >> >> > >> >> > >> >> > >> >> https://hackage.haskell.org/package/Agda-2.5.2/docs/Agda- > Utils-Functor.html > >> >> > >> >> and I think taking `for` for Applicative was name theft. > >> > > >> > > >> > This crime may no longer be charged under the statute of limitations. > >> > The > >> > federal code provides that no person can be tried or punished for any > >> > noncapital offense unless they are indicted or information is > instituted > >> > within five years of the date the offense was committed. > >> > > >> > Of course, that is here within the U.S. You might have better luck in > >> > the > >> > international court of public opinion. =) > >> > > >> > -Edward > >> > > >> > _______________________________________________ > >> > Libraries mailing list > >> > Libraries at haskell.org > >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >> > > >> _______________________________________________ > >> Libraries mailing list > >> Libraries at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnw at newartisans.com Thu Feb 23 04:51:51 2017 From: johnw at newartisans.com (John Wiegley) Date: Wed, 22 Feb 2017 20:51:51 -0800 Subject: Proposal: flipped fmap in base (again) In-Reply-To: (Elliot Cameron's message of "Wed, 22 Feb 2017 15:11:59 -0500") References: <780ef62b-b26b-840d-9013-3d6373e22d58@chalmers.se> <07a950cd-3716-3861-e29d-c9ff83b28257@chalmers.se> Message-ID: >>>>> "EC" == Elliot Cameron writes: EC> FWIW, I'm less concerned about the precise name of ffor, although it seems EC> sad to to lose the obvious correlation with fmap. Ah, it wasn't until you said that that I understood why "ffor", but now it makes some sense. :) -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 From eacameron at gmail.com Thu Feb 23 04:57:02 2017 From: eacameron at gmail.com (Elliot Cameron) Date: Wed, 22 Feb 2017 23:57:02 -0500 Subject: Proposal: flipped fmap in base (again) In-Reply-To: References: <780ef62b-b26b-840d-9013-3d6373e22d58@chalmers.se> <07a950cd-3716-3861-e29d-c9ff83b28257@chalmers.se> Message-ID: Heh, I suppose that doesn't help my case much, does it? I "derived" the name for my own uses many times prior to seeing it elsewhere (most notably Reflex: http://hackage.haskell.org/package/reflex/docs/Reflex-Class.html#v:ffor). Like I said, the name "ffor" isn't wildly important IMO. I don't want to start the "fmap should be map" debate all over again either. On Wed, Feb 22, 2017 at 11:51 PM, John Wiegley wrote: > >>>>> "EC" == Elliot Cameron writes: > > EC> FWIW, I'm less concerned about the precise name of ffor, although it > seems > EC> sad to to lose the obvious correlation with fmap. > > Ah, it wasn't until you said that that I understood why "ffor", but now it > makes some sense. :) > > -- > John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F > http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.franksen at online.de Sat Feb 25 14:12:48 2017 From: ben.franksen at online.de (Ben Franksen) Date: Sat, 25 Feb 2017 15:12:48 +0100 Subject: Proposal: Add readMaybe (and possibly readEither) to Prelude, make Haddocks for read more cautionary In-Reply-To: References: <1483011168.4381.1.camel@gmail.com> <586510F5.6080108@exmail.nottingham.ac.uk> <36DCAF4A-4590-44AB-BED3-EC1B9D7338F8@gmail.com> <06b4a138-87ed-43be-62f8-d6abd7e8e124@artyom.me> Message-ID: Am 04.01.2017 um 04:59 schrieb David Menendez: > On Tue, Jan 3, 2017 at 4:38 PM, Artyom wrote: >> Deprecating `read` is a move in the opposite direction – it makes >> hobbyists' lives harder while not changing anything for professionals >> (because half of them probably uses an in-house or alternative Prelude and >> another half can just grep for calls to `read` during the continuous >> integration build). >> > Do a lot of hobbyists use read? I’m honestly curious: I keep being told > that Read is only useful for parsing the output of Show, but I can’t > imagine that comes up a lot. I guess I could see being useful for > minimal-effort persistence, but parsers with no capacity for error messages > make me uncomfortable. I use it for numbers, mostly, typically command line arguments. Parsing number is not trivial for floats (or decmal/hex/octal/etc). Cheers Ben From m at tweag.io Sun Feb 26 20:58:43 2017 From: m at tweag.io (Boespflug, Mathieu) Date: Sun, 26 Feb 2017 21:58:43 +0100 Subject: Whither the AFPP? Message-ID: Hi all, a few folks got together to propose this nearly 2 years ago: https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath Has anything become of this proposal? Might it be helpful to have a similar process as ghc-proposals for changes in base and the boot libraries that do not otherwise affect the compiler or the language, so as to track the status of these things more consistently? Best, -- Mathieu Boespflug Founder at http://tweag.io. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.franksen at online.de Sun Feb 26 22:42:50 2017 From: ben.franksen at online.de (Ben Franksen) Date: Sun, 26 Feb 2017 23:42:50 +0100 Subject: Whither the AFPP? In-Reply-To: References: Message-ID: Am 26.02.2017 um 21:58 schrieb Boespflug, Mathieu: > a few folks got together to propose this nearly 2 years ago: > > https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath > > Has anything become of this proposal? Might it be helpful to have a similar > process as ghc-proposals for changes in base and the boot libraries that do > not otherwise affect the compiler or the language, so as to track the > status of these things more consistently? i am strongly +1, fwiw current situation is very unfortunate and this would mean progress Cheers Ben From emertens at gmail.com Mon Feb 27 00:07:55 2017 From: emertens at gmail.com (Eric Mertens) Date: Mon, 27 Feb 2017 00:07:55 +0000 Subject: Whither the AFPP? In-Reply-To: References: Message-ID: If we're going to improve the state of the file path type, it would be appropriate to first develop a package to work out the new design. Packages have already tried and failed at this, and the base package isn't the place to experiment in this space. Once this package existed and saw wide use, allowing kinks in the API to be worked out, it would then be appropriate to think about migrating base to it. Regards, Eric On Sun, Feb 26, 2017 at 2:43 PM Ben Franksen wrote: > Am 26.02.2017 um 21:58 schrieb Boespflug, Mathieu: > > a few folks got together to propose this nearly 2 years ago: > > > > https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath > > > > Has anything become of this proposal? Might it be helpful to have a > similar > > process as ghc-proposals for changes in base and the boot libraries that > do > > not otherwise affect the compiler or the language, so as to track the > > status of these things more consistently? > > i am strongly +1, fwiw > > current situation is very unfortunate and this would mean progress > > Cheers > Ben > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.franksen at online.de Mon Feb 27 00:21:08 2017 From: ben.franksen at online.de (Ben Franksen) Date: Mon, 27 Feb 2017 01:21:08 +0100 Subject: Whither the AFPP? In-Reply-To: References: Message-ID: Am 27.02.2017 um 01:07 schrieb Eric Mertens: > If we're going to improve the state of the file path type, it would be > appropriate to first develop a package to work out the new design. Packages > have already tried and failed at this, and the base package isn't the place > to experiment in this space. Once this package existed and saw wide use, > allowing kinks in the API to be worked out, it would then be appropriate to > think about migrating base to it. the way i understand the proposal it doesn'work that way, it's about a migration path in the face of many existing modules, not only base, that use the FilePath type synonym. > > Regards, > Eric > > On Sun, Feb 26, 2017 at 2:43 PM Ben Franksen wrote: > >> Am 26.02.2017 um 21:58 schrieb Boespflug, Mathieu: >>> a few folks got together to propose this nearly 2 years ago: >>> >>> https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath >>> >>> Has anything become of this proposal? Might it be helpful to have a >> similar >>> process as ghc-proposals for changes in base and the boot libraries that >> do >>> not otherwise affect the compiler or the language, so as to track the >>> status of these things more consistently? >> >> i am strongly +1, fwiw >> >> current situation is very unfortunate and this would mean progress >> >> Cheers >> Ben >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > From skosyrev at ptsecurity.com Mon Feb 27 12:19:36 2017 From: skosyrev at ptsecurity.com (Kosyrev Serge) Date: Mon, 27 Feb 2017 15:19:36 +0300 Subject: Whither the AFPP? In-Reply-To: References: Message-ID: <8760jvzuzr.fsf@ptsecurity.com> Good day! If there is an interest in prior art, /and/ there is a motivation in making things future-proof, there is that somewhat elaborate construction coming from Common Lisp: https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node203.html Quoting: > The main difficulty in dealing with names of files is that different > file systems have different naming formats for files. > > ... > > Therefore, Common Lisp provides two ways to represent file names: > namestrings, which are strings in the implementation-dependent form > customary for the file system, and pathnames, which are special abstract > data objects that represent file names in an implementation-independent > way. A particularly intriguing passage, personally, is the following one: > In order to allow Common Lisp programs to operate in a network > environment that may have more than one kind of file system, the > pathname facility allows a file name to specify which file system is to > be used. In this context, each file system is called a host, in keeping > with the usual networking terminology. > > ... > > Different hosts may use different notations for file names. Common Lisp > allows customary notation to be used for each host, but also supports a > system of logical pathnames that provides a standard framework for > naming files in a portable manner. I.e. if one squints hard enough, and reads between the lines, some shades of network transparent naming could be seen.. -- с уважениeм / respectfully, Косырев Сергей -- “Most deadly errors arise from obsolete assumptions.” -- Frank Herbert, Children of Dune From svenpanne at gmail.com Mon Feb 27 15:25:06 2017 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 27 Feb 2017 16:25:06 +0100 Subject: Whither the AFPP? In-Reply-To: <8760jvzuzr.fsf@ptsecurity.com> References: <8760jvzuzr.fsf@ptsecurity.com> Message-ID: 2017-02-27 13:19 GMT+01:00 Kosyrev Serge : > Good day! > > If there is an interest in prior art, /and/ there is a motivation in > making things future-proof, there is that somewhat elaborate construction > coming from Common Lisp: > > https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node203.html > [...] > And something more (= a quarter century ;-) recent from C++-land: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3505.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0011r0.html Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Mon Feb 27 20:42:03 2017 From: david.feuer at gmail.com (David Feuer) Date: Mon, 27 Feb 2017 15:42:03 -0500 Subject: Proposal: make throwIO and throw strict Message-ID: It's possible for code to throw an exception that itself throws an imprecise exception. Such an exception is a bit tricky to catch. For example: import Control.Exception strange = throwIO (undefined :: SomeException) `catch` \ex -> case () of _ | Just _ <- (fromException ex :: Maybe IOError) -> print "IOError" | otherwise -> print "Something else" You might think that this would catch the exception and print "Something else", but in fact it does not. If others think this is as surprising as I do, then I think we should make throwIO and throw strict, so an exception will never itself be bottom. Using throwIO' !e = throwIO e in the code above instead of throwIO allows the exception to be caught. A more conservative approach might be to just force result of toException before calling raise#, but this only works when users use an explicit type signature to fix the expression type, rather than an exception constructor. David From emertens at gmail.com Mon Feb 27 21:59:34 2017 From: emertens at gmail.com (Eric Mertens) Date: Mon, 27 Feb 2017 21:59:34 +0000 Subject: Proposal: make throwIO and throw strict In-Reply-To: References: Message-ID: Forcing the exception to WHNF doesn't do anything to resolve any of the other bottom values you might attempt to force inside your exception handler contained inside the thrown exception value. I think that the current behavior makes sense as it exists now. I'd prefer not making throwIO more magical. The user of throwIO throwing a potentially undefined exception value should take care to evaluate the exception before throwing it if that is a concern. Did this happen in some code somewhere that you discovered? It might be more compelling if we could see how this came up it some otherwise reasonable code. Regards, Eric Mertens On Mon, Feb 27, 2017 at 12:42 PM David Feuer wrote: > It's possible for code to throw an exception that itself throws an > imprecise exception. Such an exception is a bit tricky to catch. For > example: > > import Control.Exception > > strange = throwIO (undefined :: SomeException) `catch` \ex -> > case () of > _ | Just _ <- (fromException ex :: Maybe IOError) -> print "IOError" > | otherwise -> print "Something else" > > You might think that this would catch the exception and print > "Something else", but in fact it does not. If others think this is as > surprising as I do, then I think we should make throwIO and throw > strict, so an exception will never itself be bottom. Using > > throwIO' !e = throwIO e > > in the code above instead of throwIO allows the exception to be caught. > > A more conservative approach might be to just force result of > toException before calling raise#, but this only works when users use > an explicit type signature to fix the expression type, rather than an > exception constructor. > > David > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Tue Feb 28 19:07:28 2017 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 28 Feb 2017 11:07:28 -0800 Subject: Proposal: modify `Read` instances for `Float` and `Double` Message-ID: Hello, I am working on a small GHC extension to support floating point literals in hexadecimal notation (https://github.com/ghc-proposals/ghc-proposals/pull/37), which is similar to what's available in other languages. To support this change, I would like to propose that we modify the `Read` instances for `Float` and `Double` to parse literals in the new notation. This may affect existing programs---although it doesn't seem very likely. Here is an example: current behavior: reads "0x10p10" = [(16.0,"p10")] new behavior: reads "0x10p10" = [(16384,"")] What do people think? -Iavor -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Tue Feb 28 19:20:24 2017 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 28 Feb 2017 20:20:24 +0100 (CET) Subject: Proposal: modify `Read` instances for `Float` and `Double` In-Reply-To: References: Message-ID: On Tue, 28 Feb 2017, Iavor Diatchki wrote: > This may affect existing programs---although it doesn't seem very likely.  Here is an example: > > current behavior: > > reads "0x10p10" = [(16.0,"p10")] > > new behavior: > > reads "0x10p10" = [(16384,"")] "p" refers to a power of two and the exponent is written in decimal for a hexadecimal mantissa. Looks pretty confusing to me but it seems that the standard was made somewhen before this proposal.