From shumovichy at gmail.com Sat Jul 2 13:06:59 2016 From: shumovichy at gmail.com (Yuras Shumovich) Date: Sat, 02 Jul 2016 16:06:59 +0300 Subject: Interruptible exception wormholes kill modularity In-Reply-To: <1467429537-sup-6217@sabre> References: <1467429537-sup-6217@sabre> Message-ID: <1467464819.2456.4.camel@gmail.com> On Sat, 2016-07-02 at 00:49 -0400, Edward Z. Yang wrote: > > P.P.S. I have some speculations about using uninterruptibleMask more > frequently: it seems to me that there ought to be a variant of > uninterruptibleMask that immediately raises an exception if > the "uninterruptible" action blocks.  This would probably of > great assistance of noticing and eliminating blocking in > uninterruptible code. Could you please elaborate where it is useful. Any particular example? I'm interested because few years ago I proposed similar function, but in a bit different context. I needed it to make interruptible cleanup actions safe to use. Thanks, Yuras. From nicolas.godbout at gmail.com Mon Jul 4 15:32:23 2016 From: nicolas.godbout at gmail.com (Nicolas Godbout) Date: Mon, 4 Jul 2016 11:32:23 -0400 Subject: Proposal for containers: Add 'lookup' function to Data.Set In-Reply-To: References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com> Message-ID: <49C71A03-51AB-4574-8069-10ED5393CE34@gmail.com> Here is recap of the numerous answers to this proposal one week into voting. As a reminder, the original proposal is to add the following to Data.Set lookup :: Ord a => a -> Set a -> Maybe a There is essentially unconditional support for inclusion of such a function. The debate centers around the name given to the function. There were quite a number of +1 votes for the ‘lookup’ name as is. There were also quite a number of valid objections, in particular from the "containers" package containers. The final name will _not_ be 'lookup', it remains to decide what the name is. The following names have been floated so far, together with opinions (expressed on the list and my own). * lookupEQ pro: it fits in the lookupGT, lookupLT, lookupGE, lookupLE cluster of existing Data.Set functions con: the cluster set of functions have atypical names and don't seem to generate any enthusiasm on the list * find pro: closer to the semantics, similar to Data.Map.findWithDefault con: nothing to do with the signature of Data.List.find In my opinion, this one is dead. * lookupSharedPointer, lookupWithSharing, lookupIntern pro: express the intention of returning a pointer to enable sharing con: new pattern for libraries, explicitly mentions pointers which is decidedly un-Haskell-like My strong vote goes to eliminating these. Pointer behaviour is fairly obvious to expert Haskellers, but should not be mentioned to beginners. Let them ask on the Haskell mailing list why there is a 'lookup'-like function on Sets and let us just briefly mention the sharing behavior in the Haddock docs. * lookupEntry, lookupKey, lookupWithKey pro: These names are in the spirit of "container" functions. con: In the case of 'Entry', it introduces a new concept distinct from a member or element. These are the names deserving discussion and voting. There is already a (+1) for 'lookupEntry' It was mentioned that a pattern emerges with 'insertWithKey', 'adjustWithKey', 'updateWithKey' functions from Data.Map > lookupWithKey :: Ord k => k -> Map a -> Maybe (k,a) suggesting the current proposal to converge to > lookupWithKey :: Ord a => a -> Set a -> Maybe a As a side note, it was noted in several replies that all relevant "container" lookup functions should come with the guarantee that the copy from the container is returned. I vote (+1) on that! My personal take on the current matter is that whatever we choose should be compatible with Data.List. > lookup??? :: Ord a => [a] -> a -> Maybe a > lookup??? :: Ord a => a -> Set a -> Maybe a > lookup??? :: Ord k => k -> Map k a -> Maybe (k,a) where the element returned is the one from the container, enabling sharing. This kills the name 'lookup' since it is already taken in Data.List. What seems to make the most sense is 'lookupEntry', which defines the concept of 'entry' as whatever is logically stored in the container. A Map is therefore defined as logically storing key-value pairs, exactly as in an association list. +1 on 'lookupEntry' Nicolas. From nicolas.godbout at gmail.com Mon Jul 4 15:48:25 2016 From: nicolas.godbout at gmail.com (Nicolas Godbout) Date: Mon, 4 Jul 2016 11:48:25 -0400 Subject: Proposal for containers: Add 'lookup' function to Data.Set In-Reply-To: References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com> Message-ID: Correction, there are several errors in the signatures at the end of my last message. > lookup??? :: Eq a => a -> [a] -> Maybe a > lookup??? :: Ord a => a -> Set a -> Maybe a Also, copying the pattern for maps gives a slightly stranger signature > lookup??? :: (Ord k, Eq a) => (k,a) -> Map k a -> Maybe (k,a) which combines a key lookup with an equality test on the value. Nicolas. From david.feuer at gmail.com Mon Jul 4 15:49:54 2016 From: david.feuer at gmail.com (David Feuer) Date: Mon, 4 Jul 2016 11:49:54 -0400 Subject: Proposal for containers: Add 'lookup' function to Data.Set In-Reply-To: <49C71A03-51AB-4574-8069-10ED5393CE34@gmail.com> References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com> <49C71A03-51AB-4574-8069-10ED5393CE34@gmail.com> Message-ID: I think it bears mentioning that there's no need to discuss pointers to explain these functions. == in general may be coarser than structural equality, since most interesting data structures can represent the same abstract object in more than one way. So we need only explain that the result is the element stored in the set that is == to the requested value. On Jul 4, 2016 11:32 AM, "Nicolas Godbout" wrote: > > Here is recap of the numerous answers to this proposal one week into > voting. > As a reminder, the original proposal is to add the following to Data.Set > > lookup :: Ord a => a -> Set a -> Maybe a > > There is essentially unconditional support for inclusion of such a > function. The debate centers around the name given to the function. There > were quite a number of +1 votes for the ‘lookup’ name as is. There were > also quite a number of valid objections, in particular from the > "containers" package containers. The final name will _not_ be 'lookup', it > remains to decide what the name is. > > The following names have been floated so far, together with opinions > (expressed on the list and my own). > > * lookupEQ > pro: it fits in the lookupGT, lookupLT, lookupGE, lookupLE cluster of > existing Data.Set functions > con: the cluster set of functions have atypical names and don't seem > to generate any enthusiasm on the list > > * find > pro: closer to the semantics, similar to Data.Map.findWithDefault > con: nothing to do with the signature of Data.List.find > In my opinion, this one is dead. > > * lookupSharedPointer, lookupWithSharing, lookupIntern > pro: express the intention of returning a pointer to enable sharing > con: new pattern for libraries, explicitly mentions pointers which is > decidedly un-Haskell-like > My strong vote goes to eliminating these. Pointer behaviour is fairly > obvious to expert Haskellers, but should not be mentioned to beginners. Let > them ask on the Haskell mailing list why there is a 'lookup'-like function > on Sets and let us just briefly mention the sharing behavior in the Haddock > docs. > > * lookupEntry, lookupKey, lookupWithKey > pro: These names are in the spirit of "container" functions. > con: In the case of 'Entry', it introduces a new concept distinct from > a member or element. > These are the names deserving discussion and voting. There is already a > (+1) for 'lookupEntry' > It was mentioned that a pattern emerges with 'insertWithKey', > 'adjustWithKey', 'updateWithKey' functions from Data.Map > > lookupWithKey :: Ord k => k -> Map a -> Maybe (k,a) > suggesting the current proposal to converge to > > lookupWithKey :: Ord a => a -> Set a -> Maybe a > > As a side note, it was noted in several replies that all relevant > "container" lookup functions should come with the guarantee that the copy > from the container is returned. I vote (+1) on that! > > My personal take on the current matter is that whatever we choose should > be compatible with Data.List. > > lookup??? :: Ord a => [a] -> a -> Maybe a > > lookup??? :: Ord a => a -> Set a -> Maybe a > > lookup??? :: Ord k => k -> Map k a -> Maybe (k,a) > where the element returned is the one from the container, enabling > sharing. This kills the name 'lookup' since it is already taken in > Data.List. What seems to make the most sense is 'lookupEntry', which > defines the concept of 'entry' as whatever is logically stored in the > container. A Map is therefore defined as logically storing key-value pairs, > exactly as in an association list. > > +1 on 'lookupEntry' > > > Nicolas. > > > > _______________________________________________ > 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 Mon Jul 4 15:53:32 2016 From: david.feuer at gmail.com (David Feuer) Date: Mon, 4 Jul 2016 11:53:32 -0400 Subject: Proposal for containers: Add 'lookup' function to Data.Set In-Reply-To: References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com> Message-ID: What we want for Map is definitely not that, but rather ??? :: Ord k => k -> Map k v -> Maybe (k, v) In each case we look up a key to retrieve an "entry" (whether we want that terminology or not). In the case of a Map, the entry is a key-value pair; in the case of a Set it is merely a key. On Jul 4, 2016 11:48 AM, "Nicolas Godbout" wrote: Correction, there are several errors in the signatures at the end of my last message. > lookup??? :: Eq a => a -> [a] -> Maybe a > lookup??? :: Ord a => a -> Set a -> Maybe a Also, copying the pattern for maps gives a slightly stranger signature > lookup??? :: (Ord k, Eq a) => (k,a) -> Map k a -> Maybe (k,a) which combines a key lookup with an equality test on the value. Nicolas. _______________________________________________ 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 nicolas.godbout at gmail.com Mon Jul 4 16:18:24 2016 From: nicolas.godbout at gmail.com (Nicolas Godbout) Date: Mon, 4 Jul 2016 12:18:24 -0400 Subject: Proposal for containers: Add 'lookup' function to Data.Set In-Reply-To: References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com> Message-ID: <83551726-CB46-4EED-8275-F208724BEAF8@gmail.com> > Le 4 juil. 2016 à 11:53, David Feuer a écrit : > > What we want for Map is definitely not that, but rather > > ??? :: Ord k => k -> Map k v -> Maybe (k, v) > > In each case we look up a key to retrieve an "entry" (whether we want that terminology or not). In the case of a Map, the entry is a key-value pair; in the case of a Set it is merely a key. > Agreed. However, I am still scratching my head about how the functions we are considering would behave on Lists. The existence of 'Data.List.lookup' also muddles the issues since it works on association lists and not just any list. The challenge: find a name '???' such that all three of the following make sense: ??? :: Ord a => a -> Set a -> Maybe a ??? :: Eq a => a -> [a] -> Maybe a ??? :: Ord k => k -> Map k v -> Maybe (k, v) A name such a 'lookupKey' looks weird on lists and sets. It is not quite a "containers" problem, but it would be nice to be compatible with "base" names. Under this spotlight, what makes sense is 'lookupElem' where elements of lists and sets are obvious, and the elements of a Map are defined as the key-value pairs. Data.Map currently has no function on elements, so this avenue seems open and viable. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Mon Jul 4 16:50:03 2016 From: david.feuer at gmail.com (David Feuer) Date: Mon, 4 Jul 2016 12:50:03 -0400 Subject: Proposal for containers: Add 'lookup' function to Data.Set In-Reply-To: <83551726-CB46-4EED-8275-F208724BEAF8@gmail.com> References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com> <83551726-CB46-4EED-8275-F208724BEAF8@gmail.com> Message-ID: I barely care about Data.List association lists. They have no business being in Data.List at all. If compatibility with association lists gets in the way of a good interface, I'll take the good interface anyway. On Jul 4, 2016 12:18 PM, "Nicolas Godbout" wrote: > > > Le 4 juil. 2016 à 11:53, David Feuer a écrit : > > What we want for Map is definitely not that, but rather > > ??? :: Ord k => k -> Map k v -> Maybe (k, v) > > In each case we look up a key to retrieve an "entry" (whether we want that > terminology or not). In the case of a Map, the entry is a key-value pair; > in the case of a Set it is merely a key. > > Agreed. > > However, I am still scratching my head about how the functions we are > considering would behave on Lists. The existence of 'Data.List.lookup' also > muddles the issues since it works on association lists and not just any > list. > > The challenge: find a name '???' such that all three of the following make > sense: > > ??? :: Ord a => a -> Set a -> Maybe a > ??? :: Eq a => a -> [a] -> Maybe a > ??? :: Ord k => k -> Map k v -> Maybe (k, v) > > A name such a 'lookupKey' looks weird on lists and sets. It is not quite a > "containers" problem, but it would be nice to be compatible with "base" > names. > > Under this spotlight, what makes sense is 'lookupElem' where elements of > lists and sets are obvious, and the elements of a Map are defined as the > key-value pairs. Data.Map currently has no function on elements, so this > avenue seems open and viable. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Mon Jul 4 18:46:49 2016 From: david.feuer at gmail.com (David Feuer) Date: Mon, 4 Jul 2016 14:46:49 -0400 Subject: Proposal for containers: Add 'lookup' function to Data.Set In-Reply-To: <49C71A03-51AB-4574-8069-10ED5393CE34@gmail.com> References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com> <49C71A03-51AB-4574-8069-10ED5393CE34@gmail.com> Message-ID: To add to the summary, we also considered a function to insert an element into a set or a pair into a map preserving the existing key. For maps, we'd want a variant of insertWithKey, I suppose. TBH, I find the current insertion behavior perplexing. Perhaps it would make sense to add modules with more sensible insertion functions? How much risk is there of breaking things by changing the behavior of the current functions to *preserve* elements/keys rather than replacing them, and making insertWithKey give the passed function the stored key rather than the given one? On Jul 4, 2016 11:32 AM, "Nicolas Godbout" wrote: > > Here is recap of the numerous answers to this proposal one week into > voting. > As a reminder, the original proposal is to add the following to Data.Set > > lookup :: Ord a => a -> Set a -> Maybe a > > There is essentially unconditional support for inclusion of such a > function. The debate centers around the name given to the function. There > were quite a number of +1 votes for the ‘lookup’ name as is. There were > also quite a number of valid objections, in particular from the > "containers" package containers. The final name will _not_ be 'lookup', it > remains to decide what the name is. > > The following names have been floated so far, together with opinions > (expressed on the list and my own). > > * lookupEQ > pro: it fits in the lookupGT, lookupLT, lookupGE, lookupLE cluster of > existing Data.Set functions > con: the cluster set of functions have atypical names and don't seem > to generate any enthusiasm on the list > > * find > pro: closer to the semantics, similar to Data.Map.findWithDefault > con: nothing to do with the signature of Data.List.find > In my opinion, this one is dead. > > * lookupSharedPointer, lookupWithSharing, lookupIntern > pro: express the intention of returning a pointer to enable sharing > con: new pattern for libraries, explicitly mentions pointers which is > decidedly un-Haskell-like > My strong vote goes to eliminating these. Pointer behaviour is fairly > obvious to expert Haskellers, but should not be mentioned to beginners. Let > them ask on the Haskell mailing list why there is a 'lookup'-like function > on Sets and let us just briefly mention the sharing behavior in the Haddock > docs. > > * lookupEntry, lookupKey, lookupWithKey > pro: These names are in the spirit of "container" functions. > con: In the case of 'Entry', it introduces a new concept distinct from > a member or element. > These are the names deserving discussion and voting. There is already a > (+1) for 'lookupEntry' > It was mentioned that a pattern emerges with 'insertWithKey', > 'adjustWithKey', 'updateWithKey' functions from Data.Map > > lookupWithKey :: Ord k => k -> Map a -> Maybe (k,a) > suggesting the current proposal to converge to > > lookupWithKey :: Ord a => a -> Set a -> Maybe a > > As a side note, it was noted in several replies that all relevant > "container" lookup functions should come with the guarantee that the copy > from the container is returned. I vote (+1) on that! > > My personal take on the current matter is that whatever we choose should > be compatible with Data.List. > > lookup??? :: Ord a => [a] -> a -> Maybe a > > lookup??? :: Ord a => a -> Set a -> Maybe a > > lookup??? :: Ord k => k -> Map k a -> Maybe (k,a) > where the element returned is the one from the container, enabling > sharing. This kills the name 'lookup' since it is already taken in > Data.List. What seems to make the most sense is 'lookupEntry', which > defines the concept of 'entry' as whatever is logically stored in the > container. A Map is therefore defined as logically storing key-value pairs, > exactly as in an association list. > > +1 on 'lookupEntry' > > > Nicolas. > > > > _______________________________________________ > 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 Jul 8 17:49:12 2016 From: david.feuer at gmail.com (David Feuer) Date: Fri, 8 Jul 2016 13:49:12 -0400 Subject: Proposal and discussion: Deprecate Data.Set.mapMonotonic and Data.Map.mapKeysMonotonic; add correctly named functions Message-ID: We currently have a function mapMonotonic in Data.Set and one called mapKeysMonotonic in Data.Map. These names are confusing for two reasons: 1. In some mathematical contexts, a function is considered monotonic if it's *either* increasing or decreasing. 2. Even where monotonic specifically means *increasing*, it generally does *not* specifically mean *strictly increasing*. The functions in question work when, and only when, the given function is strictly increasing on the elements/keys in the set/map. I'd like to DEPRECATE these functions, and add new ones: Data.Set: mapStrictlyIncreasing and mapStrictlyDecreasing Data.Map: mapKeysStrictlyIncreasing and mapKeysStrictlyDecreasing Data.Map presents another possibility, however. We could make the replacements more general, giving them types Ord k => (k -> v -> (k', v')) -> Map k v -> Map k' v' and allowing the user to map over both keys and values in one pass. David Feuer From ivan.miljenovic at gmail.com Fri Jul 8 23:18:19 2016 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Sat, 9 Jul 2016 09:18:19 +1000 Subject: Proposal and discussion: Deprecate Data.Set.mapMonotonic and Data.Map.mapKeysMonotonic; add correctly named functions In-Reply-To: References: Message-ID: On 9 July 2016 at 03:49, David Feuer wrote: > We currently have a function mapMonotonic in Data.Set and one called > mapKeysMonotonic in Data.Map. These names are confusing for two > reasons: > > 1. In some mathematical contexts, a function is considered monotonic > if it's *either* increasing or decreasing. > > 2. Even where monotonic specifically means *increasing*, it generally > does *not* specifically mean *strictly increasing*. > > The functions in question work when, and only when, the given function > is strictly increasing on the elements/keys in the set/map. > > I'd like to DEPRECATE these functions, and add new ones: > > Data.Set: mapStrictlyIncreasing and mapStrictlyDecreasing > Data.Map: mapKeysStrictlyIncreasing and mapKeysStrictlyDecreasing With the latter function also flipping the underlying tree structure? > Data.Map presents another possibility, however. We could make the > replacements more general, giving them types > > Ord k => (k -> v -> (k', v')) -> Map k v -> Map k' v' > > and allowing the user to map over both keys and values in one pass. Though IIUC this provides no way of specifying that "I'm sure this function has a 1-1 monotonic relationship so you can just update the keys without changing the structure" (in the sense of there's no way to distinguish between the increasing and decreasing sense). Overall, I'm about +0.5 from the naming sense of the current functions, but have used these in the past. -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From david.feuer at gmail.com Sat Jul 9 00:28:34 2016 From: david.feuer at gmail.com (David Feuer) Date: Fri, 8 Jul 2016 20:28:34 -0400 Subject: Proposal and discussion: Deprecate Data.Set.mapMonotonic and Data.Map.mapKeysMonotonic; add correctly named functions In-Reply-To: References: Message-ID: On Jul 8, 2016 7:18 PM, "Ivan Lazar Miljenovic" wrote: > > On 9 July 2016 at 03:49, David Feuer wrote: > > Data.Set: mapStrictlyIncreasing and mapStrictlyDecreasing > > Data.Map: mapKeysStrictlyIncreasing and mapKeysStrictlyDecreasing > > With the latter function also flipping the underlying tree structure? I'm not quite sure what you mean, but I think the answer is yes. mapKeysStrictlyDecreasing (\x -> -x) (fromList [1..10]) === fromList [(-10) .. (-1)] > > > Data.Map presents another possibility, however. We could make the > > replacements more general, giving them types > > > > Ord k => (k -> v -> (k', v')) -> Map k v -> Map k' v' > > > > and allowing the user to map over both keys and values in one pass. > > Though IIUC this provides no way of specifying that "I'm sure this > function has a 1-1 monotonic relationship so you can just update the > keys without changing the structure" (in the sense of there's no way > to distinguish between the increasing and decreasing sense). That is the pre-condition. There still needs to be one for strictly increasing functions and another for strictly decreasing ones, since they lead to reversed tree structures. > > Overall, I'm about +0.5 from the naming sense of the current > functions, but have used these in the past. I don't understand this statement. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abela at chalmers.se Mon Jul 11 10:12:31 2016 From: abela at chalmers.se (Andreas Abel) Date: Mon, 11 Jul 2016 12:12:31 +0200 Subject: Proposal and discussion: Deprecate Data.Set.mapMonotonic and Data.Map.mapKeysMonotonic; add correctly named functions In-Reply-To: References: Message-ID: <5783710F.3060600@chalmers.se> I thought the current functions are quite clear with a bit of common sense. They assume the renaming of keys does not change their relative order, so the underlying tree structure of the map/set can remain as-is. Of course, as you point out, the names are not precise, but cannot the documentation add what is not reflected in the names? The question is, as always, if the breakage caused by the renaming compensates for having the optimal name. I am slightly biased against the renaming. --Andreas On 09.07.2016 02:28, David Feuer wrote: > > On Jul 8, 2016 7:18 PM, "Ivan Lazar Miljenovic" > > wrote: > > > > On 9 July 2016 at 03:49, David Feuer > wrote: > > > > Data.Set: mapStrictlyIncreasing and mapStrictlyDecreasing > > > Data.Map: mapKeysStrictlyIncreasing and mapKeysStrictlyDecreasing > > > > With the latter function also flipping the underlying tree structure? > > I'm not quite sure what you mean, but I think the answer is yes. > > mapKeysStrictlyDecreasing (\x -> -x) (fromList [1..10]) === fromList > [(-10) .. (-1)] > > > > > > Data.Map presents another possibility, however. We could make the > > > replacements more general, giving them types > > > > > > Ord k => (k -> v -> (k', v')) -> Map k v -> Map k' v' > > > > > > and allowing the user to map over both keys and values in one pass. > > > > Though IIUC this provides no way of specifying that "I'm sure this > > function has a 1-1 monotonic relationship so you can just update the > > keys without changing the structure" (in the sense of there's no way > > to distinguish between the increasing and decreasing sense). > > That is the pre-condition. There still needs to be one for strictly > increasing functions and another for strictly decreasing ones, since > they lead to reversed tree structures. > > > > > Overall, I'm about +0.5 from the naming sense of the current > > functions, but have used these in the past. > > I don't understand this statement. > > > > _______________________________________________ > 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://www2.tcs.ifi.lmu.de/~abel/ From david.feuer at gmail.com Tue Jul 12 00:23:53 2016 From: david.feuer at gmail.com (David Feuer) Date: Mon, 11 Jul 2016 20:23:53 -0400 Subject: Discussion: add more idiomatic versions of catchJust and/or handleJust In-Reply-To: References: Message-ID: The catchJust and handleJust functions seem a bit weird and unidiomatic. catchJust :: Exception e => (e -> Maybe b) -- ^ Predicate to select exceptions -> IO a -- ^ Computation to run -> (b -> IO a) -- ^ Handler -> IO a catchJust p a handler = catch a handler' where handler' e = case p e of Nothing -> throwIO e Just b -> handler b This takes two functions and then puts them together. I would think the more natural API would be catchMaybe :: Exception e => IO a -> (e -> Maybe (IO a)) -> IO a catchMaybe m handler = catch m handler' where handler' e = fromMaybe (throwIO e) (handler e) This is exactly as powerful as catchJust: catchMaybe m handler = catchJust handler m id catchJust p m handler = catchMaybe m $ fmap handler . p But catchMaybe doesn't enforce the arbitrary separation between "selection" and "handling". -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Tue Jul 12 05:44:53 2016 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 12 Jul 2016 01:44:53 -0400 Subject: Proposal and discussion: Deprecate Data.Set.mapMonotonic and Data.Map.mapKeysMonotonic; add correctly named functions In-Reply-To: <5783710F.3060600@chalmers.se> References: <5783710F.3060600@chalmers.se> Message-ID: I'm also slightly biased against renaming, as the intent is signaled pretty clearly. -Edward On Mon, Jul 11, 2016 at 6:12 AM, Andreas Abel wrote: > I thought the current functions are quite clear with a bit of common > sense. They assume the renaming of keys does not change their relative > order, so the underlying tree structure of the map/set can remain as-is. > > Of course, as you point out, the names are not precise, but cannot the > documentation add what is not reflected in the names? > > The question is, as always, if the breakage caused by the renaming > compensates for having the optimal name. I am slightly biased against the > renaming. > > --Andreas > > > On 09.07.2016 02:28, David Feuer wrote: > >> >> On Jul 8, 2016 7:18 PM, "Ivan Lazar Miljenovic" >> > wrote: >> > >> > On 9 July 2016 at 03:49, David Feuer > > wrote: >> >> > > Data.Set: mapStrictlyIncreasing and mapStrictlyDecreasing >> > > Data.Map: mapKeysStrictlyIncreasing and mapKeysStrictlyDecreasing >> > >> > With the latter function also flipping the underlying tree structure? >> >> I'm not quite sure what you mean, but I think the answer is yes. >> >> mapKeysStrictlyDecreasing (\x -> -x) (fromList [1..10]) === fromList >> [(-10) .. (-1)] >> >> > >> > > Data.Map presents another possibility, however. We could make the >> > > replacements more general, giving them types >> > > >> > > Ord k => (k -> v -> (k', v')) -> Map k v -> Map k' v' >> > > >> > > and allowing the user to map over both keys and values in one pass. >> > >> > Though IIUC this provides no way of specifying that "I'm sure this >> > function has a 1-1 monotonic relationship so you can just update the >> > keys without changing the structure" (in the sense of there's no way >> > to distinguish between the increasing and decreasing sense). >> >> That is the pre-condition. There still needs to be one for strictly >> increasing functions and another for strictly decreasing ones, since >> they lead to reversed tree structures. >> >> > >> > Overall, I'm about +0.5 from the naming sense of the current >> > functions, but have used these in the past. >> >> I don't understand this statement. >> >> >> >> _______________________________________________ >> 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://www2.tcs.ifi.lmu.de/~abel/ > > _______________________________________________ > 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 Tue Jul 12 05:49:24 2016 From: david.feuer at gmail.com (David Feuer) Date: Tue, 12 Jul 2016 01:49:24 -0400 Subject: Proposal and discussion: Deprecate Data.Set.mapMonotonic and Data.Map.mapKeysMonotonic; add correctly named functions In-Reply-To: References: <5783710F.3060600@chalmers.se> Message-ID: Fine. Sounds like I lose this one. Should the duals be mapAntitone and mapKeysAntitone? On Jul 12, 2016 1:44 AM, "Edward Kmett" wrote: > I'm also slightly biased against renaming, as the intent is signaled > pretty clearly. > > -Edward > > On Mon, Jul 11, 2016 at 6:12 AM, Andreas Abel wrote: > >> I thought the current functions are quite clear with a bit of common >> sense. They assume the renaming of keys does not change their relative >> order, so the underlying tree structure of the map/set can remain as-is. >> >> Of course, as you point out, the names are not precise, but cannot the >> documentation add what is not reflected in the names? >> >> The question is, as always, if the breakage caused by the renaming >> compensates for having the optimal name. I am slightly biased against the >> renaming. >> >> --Andreas >> >> >> On 09.07.2016 02:28, David Feuer wrote: >> >>> >>> On Jul 8, 2016 7:18 PM, "Ivan Lazar Miljenovic" >>> > wrote: >>> > >>> > On 9 July 2016 at 03:49, David Feuer >> > wrote: >>> >>> > > Data.Set: mapStrictlyIncreasing and mapStrictlyDecreasing >>> > > Data.Map: mapKeysStrictlyIncreasing and mapKeysStrictlyDecreasing >>> > >>> > With the latter function also flipping the underlying tree structure? >>> >>> I'm not quite sure what you mean, but I think the answer is yes. >>> >>> mapKeysStrictlyDecreasing (\x -> -x) (fromList [1..10]) === fromList >>> [(-10) .. (-1)] >>> >>> > >>> > > Data.Map presents another possibility, however. We could make the >>> > > replacements more general, giving them types >>> > > >>> > > Ord k => (k -> v -> (k', v')) -> Map k v -> Map k' v' >>> > > >>> > > and allowing the user to map over both keys and values in one pass. >>> > >>> > Though IIUC this provides no way of specifying that "I'm sure this >>> > function has a 1-1 monotonic relationship so you can just update the >>> > keys without changing the structure" (in the sense of there's no way >>> > to distinguish between the increasing and decreasing sense). >>> >>> That is the pre-condition. There still needs to be one for strictly >>> increasing functions and another for strictly decreasing ones, since >>> they lead to reversed tree structures. >>> >>> > >>> > Overall, I'm about +0.5 from the naming sense of the current >>> > functions, but have used these in the past. >>> >>> I don't understand this statement. >>> >>> >>> >>> _______________________________________________ >>> 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://www2.tcs.ifi.lmu.de/~abel/ >> >> _______________________________________________ >> 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 Tue Jul 12 14:32:26 2016 From: abela at chalmers.se (Andreas Abel) Date: Tue, 12 Jul 2016 16:32:26 +0200 Subject: Proposal and discussion: Deprecate Data.Set.mapMonotonic and Data.Map.mapKeysMonotonic; add correctly named functions In-Reply-To: References: <5783710F.3060600@chalmers.se> Message-ID: <5784FF7A.4020807@chalmers.se> +1 That would be consistent ;) (in some sense at least). On 12.07.2016 07:49, David Feuer wrote: > Fine. Sounds like I lose this one. Should the duals be mapAntitone and > mapKeysAntitone? > > On Jul 12, 2016 1:44 AM, "Edward Kmett" > wrote: > > I'm also slightly biased against renaming, as the intent is signaled > pretty clearly. > > -Edward > > On Mon, Jul 11, 2016 at 6:12 AM, Andreas Abel > wrote: > > I thought the current functions are quite clear with a bit of > common sense. They assume the renaming of keys does not change > their relative order, so the underlying tree structure of the > map/set can remain as-is. > > Of course, as you point out, the names are not precise, but > cannot the documentation add what is not reflected in the names? > > The question is, as always, if the breakage caused by the > renaming compensates for having the optimal name. I am slightly > biased against the renaming. > > --Andreas > > > On 09.07.2016 02:28, David Feuer wrote: > > > On Jul 8, 2016 7:18 PM, "Ivan Lazar Miljenovic" > > >> wrote: > > > > On 9 July 2016 at 03:49, David Feuer > > >> wrote: > > > > Data.Set: mapStrictlyIncreasing and mapStrictlyDecreasing > > > Data.Map: mapKeysStrictlyIncreasing and > mapKeysStrictlyDecreasing > > > > With the latter function also flipping the underlying > tree structure? > > I'm not quite sure what you mean, but I think the answer is yes. > > mapKeysStrictlyDecreasing (\x -> -x) (fromList [1..10]) === > fromList > [(-10) .. (-1)] > > > > > > Data.Map presents another possibility, however. We > could make the > > > replacements more general, giving them types > > > > > > Ord k => (k -> v -> (k', v')) -> Map k v -> Map k' v' > > > > > > and allowing the user to map over both keys and values > in one pass. > > > > Though IIUC this provides no way of specifying that "I'm > sure this > > function has a 1-1 monotonic relationship so you can > just update the > > keys without changing the structure" (in the sense of > there's no way > > to distinguish between the increasing and decreasing sense). > > That is the pre-condition. There still needs to be one for > strictly > increasing functions and another for strictly decreasing > ones, since > they lead to reversed tree structures. > > > > > Overall, I'm about +0.5 from the naming sense of the current > > functions, but have used these in the past. > > I don't understand this statement. > > > > _______________________________________________ > 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://www2.tcs.ifi.lmu.de/~abel/ > > _______________________________________________ > 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://www2.tcs.ifi.lmu.de/~abel/ From andreas.abel at ifi.lmu.de Wed Jul 13 19:36:28 2016 From: andreas.abel at ifi.lmu.de (Andreas Abel) Date: Wed, 13 Jul 2016 21:36:28 +0200 Subject: Discussion: add more idiomatic versions of catchJust and/or handleJust In-Reply-To: References: Message-ID: <5786983C.7000103@ifi.lmu.de> I can only guess why catchJust was designed like it is. A type like b -> Maybe (IO a) is not as intuitive as the types e -> Maybe b -- ^ if you do not understand this, get back to Haskell school! b -> IO a -- ^ a continuation, we know this from >>= and friends A type like Maybe (IO a) is more unusual, requires more thinking. +-0. I have no opinion on what is better. On 12.07.2016 02:23, David Feuer wrote: > The catchJust and handleJust functions seem a bit weird and unidiomatic. > > catchJust > :: Exception e > => (e -> Maybe b) -- ^ Predicate to select exceptions > -> IO a -- ^ Computation to run > -> (b -> IO a) -- ^ Handler > -> IO a > catchJust p a handler = catch a handler' > where handler' e = case p e of > Nothing -> throwIO e > Just b -> handler b > > This takes two functions and then puts them together. I would think the > more natural API would be > > catchMaybe :: Exception e => IO a -> (e -> Maybe (IO a)) -> IO a > catchMaybe m handler = catch m handler' where > handler' e = fromMaybe (throwIO e) (handler e) > > This is exactly as powerful as catchJust: > > catchMaybe m handler = catchJust handler m id > catchJust p m handler = catchMaybe m $ fmap handler . p > > But catchMaybe doesn't enforce the arbitrary separation between > "selection" and "handling". > > > > _______________________________________________ > 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://www2.tcs.ifi.lmu.de/~abel/ From david.feuer at gmail.com Wed Jul 13 20:14:46 2016 From: david.feuer at gmail.com (David Feuer) Date: Wed, 13 Jul 2016 16:14:46 -0400 Subject: Discussion: add more idiomatic versions of catchJust and/or handleJust In-Reply-To: <5786983C.7000103@ifi.lmu.de> References: <5786983C.7000103@ifi.lmu.de> Message-ID: I hate having to make arbitrary choices when writing code. With `catchJust`, I have to decide what to calculate in the selector and what to calculate in the handler. As far as I can tell, there's never any reason to leave any calculation for the handler. I don't think the `Maybe (IO a)` type is nearly as hard to think about as exceptions themselves are. The handler either provides a recovery action or it doesn't. The catchMaybe signature strikes me, personally, as easier to understand, because I don't need to use parametricity to string the pieces together. On Wed, Jul 13, 2016 at 3:36 PM, Andreas Abel wrote: > I can only guess why catchJust was designed like it is. A type like > > b -> Maybe (IO a) > > is not as intuitive as the types > > e -> Maybe b > -- ^ if you do not understand this, get back to Haskell school! > > b -> IO a > -- ^ a continuation, we know this from >>= and friends > > A type like Maybe (IO a) is more unusual, requires more thinking. > > +-0. I have no opinion on what is better. > > > On 12.07.2016 02:23, David Feuer wrote: >> >> The catchJust and handleJust functions seem a bit weird and unidiomatic. >> >> catchJust >> :: Exception e >> => (e -> Maybe b) -- ^ Predicate to select exceptions >> -> IO a -- ^ Computation to run >> -> (b -> IO a) -- ^ Handler >> -> IO a >> catchJust p a handler = catch a handler' >> where handler' e = case p e of >> Nothing -> throwIO e >> Just b -> handler b >> >> This takes two functions and then puts them together. I would think the >> more natural API would be >> >> catchMaybe :: Exception e => IO a -> (e -> Maybe (IO a)) -> IO a >> catchMaybe m handler = catch m handler' where >> handler' e = fromMaybe (throwIO e) (handler e) >> >> This is exactly as powerful as catchJust: >> >> catchMaybe m handler = catchJust handler m id >> catchJust p m handler = catchMaybe m $ fmap handler . p >> >> But catchMaybe doesn't enforce the arbitrary separation between >> "selection" and "handling". >> >> >> >> _______________________________________________ >> 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://www2.tcs.ifi.lmu.de/~abel/ From tanuki at gmail.com Wed Jul 13 21:23:04 2016 From: tanuki at gmail.com (Theodore Lief Gannon) Date: Wed, 13 Jul 2016 14:23:04 -0700 Subject: Discussion: add more idiomatic versions of catchJust and/or handleJust In-Reply-To: References: <5786983C.7000103@ifi.lmu.de> Message-ID: +1 on catchMaybe from this corner of the peanut gallery, FWIW. It feels far more idiomatic, and provides the same power with fewer moving parts. On Jul 13, 2016 1:14 PM, "David Feuer" wrote: > I hate having to make arbitrary choices when writing code. With > `catchJust`, I have to decide what to calculate in the selector and > what to calculate in the handler. As far as I can tell, there's never > any reason to leave any calculation for the handler. > > I don't think the `Maybe (IO a)` type is nearly as hard to think about > as exceptions themselves are. The handler either provides a recovery > action or it doesn't. The catchMaybe signature strikes me, personally, > as easier to understand, because I don't need to use parametricity to > string the pieces together. > > On Wed, Jul 13, 2016 at 3:36 PM, Andreas Abel > wrote: > > I can only guess why catchJust was designed like it is. A type like > > > > b -> Maybe (IO a) > > > > is not as intuitive as the types > > > > e -> Maybe b > > -- ^ if you do not understand this, get back to Haskell school! > > > > b -> IO a > > -- ^ a continuation, we know this from >>= and friends > > > > A type like Maybe (IO a) is more unusual, requires more thinking. > > > > +-0. I have no opinion on what is better. > > > > > > On 12.07.2016 02:23, David Feuer wrote: > >> > >> The catchJust and handleJust functions seem a bit weird and unidiomatic. > >> > >> catchJust > >> :: Exception e > >> => (e -> Maybe b) -- ^ Predicate to select exceptions > >> -> IO a -- ^ Computation to run > >> -> (b -> IO a) -- ^ Handler > >> -> IO a > >> catchJust p a handler = catch a handler' > >> where handler' e = case p e of > >> Nothing -> throwIO e > >> Just b -> handler b > >> > >> This takes two functions and then puts them together. I would think the > >> more natural API would be > >> > >> catchMaybe :: Exception e => IO a -> (e -> Maybe (IO a)) -> IO a > >> catchMaybe m handler = catch m handler' where > >> handler' e = fromMaybe (throwIO e) (handler e) > >> > >> This is exactly as powerful as catchJust: > >> > >> catchMaybe m handler = catchJust handler m id > >> catchJust p m handler = catchMaybe m $ fmap handler . p > >> > >> But catchMaybe doesn't enforce the arbitrary separation between > >> "selection" and "handling". > >> > >> > >> > >> _______________________________________________ > >> 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://www2.tcs.ifi.lmu.de/~abel/ > _______________________________________________ > 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 Thu Jul 14 03:16:27 2016 From: david.feuer at gmail.com (David Feuer) Date: Wed, 13 Jul 2016 23:16:27 -0400 Subject: Proposal: Add Foldable helper to Control.DeepSeq Message-ID: As I describe in https://github.com/haskell/deepseq/issues/17 it is possible to implement an NFData instance for any Foldable type, and we can offer a function to help do that: data Unit = Unit instance Monoid Unit where mempty = Unit Unit `mappend` Unit = Unit -- strict in both arguments, unlike () rnfFoldable :: (Foldable f, NFData a) => f a -> () rnfFoldable xs = foldMap (\x -> rnf x `seq` Unit) xs `seq` () This could be used like so: instance NFData a => NFData (F a) where rnf = rnfFoldable This version forces from left to right. It would be possible to offer another version that forces from right to left: data Unit2 = Unit2 instance Monoid Unit2 where mempty = Unit2 x `mappend` Unit2 = x `seq` Unit2 rnfFoldableRTL :: (Foldable f, NFData a) => f a -> () rnfFoldableRTL xs = foldMap (\x -> rnf x `seq` Unit2) xs `seq` () From david.feuer at gmail.com Thu Jul 14 04:45:27 2016 From: david.feuer at gmail.com (David Feuer) Date: Thu, 14 Jul 2016 00:45:27 -0400 Subject: Proposal: Add `restriction` to Data.Map and Data.IntMap Message-ID: Cale Gibbard proposes the following: Data.IntMap.restriction :: IntSet -> IntMap a -> IntMap a Data.Map.restriction :: Ord k => Set k -> Map k a -> Map k a In each case, the map is filtered to contain only the keys that are also found in the set. This can be implemented efficiently using a slightly stripped-down version of Data.Map.intersection. David Feuer From ivan.miljenovic at gmail.com Thu Jul 14 07:42:21 2016 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Thu, 14 Jul 2016 17:42:21 +1000 Subject: Proposal: Add `restriction` to Data.Map and Data.IntMap In-Reply-To: References: Message-ID: On 14 July 2016 at 14:45, David Feuer wrote: > Cale Gibbard proposes the following: > > Data.IntMap.restriction :: IntSet -> IntMap a -> IntMap a > Data.Map.restriction :: Ord k => Set k -> Map k a -> Map k a > > In each case, the map is filtered to contain only the keys that are > also found in the set. This can be implemented efficiently using a > slightly stripped-down version of Data.Map.intersection. +1 I've bodged up similar things in the past, so this would be appreciated. -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From abela at chalmers.se Thu Jul 14 09:38:01 2016 From: abela at chalmers.se (Andreas Abel) Date: Thu, 14 Jul 2016 11:38:01 +0200 Subject: Proposal: Add Foldable helper to Control.DeepSeq In-Reply-To: References: Message-ID: <57875D79.4010404@chalmers.se> +1 LGTM On 14.07.2016 05:16, David Feuer wrote: > As I describe in https://github.com/haskell/deepseq/issues/17 it is > possible to implement an NFData instance for any Foldable type, and we > can offer a function to help do that: > > data Unit = Unit > > instance Monoid Unit where > mempty = Unit > Unit `mappend` Unit = Unit -- strict in both arguments, unlike () > > rnfFoldable :: (Foldable f, NFData a) => f a -> () > rnfFoldable xs = foldMap (\x -> rnf x `seq` Unit) xs `seq` () > > This could be used like so: > > instance NFData a => NFData (F a) where > rnf = rnfFoldable > > This version forces from left to right. It would be possible to offer > another version that forces from right to left: > > data Unit2 = Unit2 > > instance Monoid Unit2 where > mempty = Unit2 > x `mappend` Unit2 = x `seq` Unit2 > > rnfFoldableRTL :: (Foldable f, NFData a) => f a -> () > rnfFoldableRTL xs = foldMap (\x -> rnf x `seq` Unit2) xs `seq` () > _______________________________________________ > 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://www2.tcs.ifi.lmu.de/~abel/ From abela at chalmers.se Thu Jul 14 09:39:04 2016 From: abela at chalmers.se (Andreas Abel) Date: Thu, 14 Jul 2016 11:39:04 +0200 Subject: Proposal: Add `restriction` to Data.Map and Data.IntMap In-Reply-To: References: Message-ID: <57875DB8.8040505@chalmers.se> +1. On 14.07.2016 06:45, David Feuer wrote: > Cale Gibbard proposes the following: > > Data.IntMap.restriction :: IntSet -> IntMap a -> IntMap a > Data.Map.restriction :: Ord k => Set k -> Map k a -> Map k a > > In each case, the map is filtered to contain only the keys that are > also found in the set. This can be implemented efficiently using a > slightly stripped-down version of Data.Map.intersection. > > David Feuer > _______________________________________________ > 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://www2.tcs.ifi.lmu.de/~abel/ From jake.mcarthur at gmail.com Thu Jul 14 12:45:17 2016 From: jake.mcarthur at gmail.com (Jake McArthur) Date: Thu, 14 Jul 2016 12:45:17 +0000 Subject: Proposal: Add `restriction` to Data.Map and Data.IntMap In-Reply-To: <57875DB8.8040505@chalmers.se> References: <57875DB8.8040505@chalmers.se> Message-ID: I like the function, but I'd like to bikeshed a bit. The name "restriction" seems confusing to me, or at least I don't understand the etymology. As of now I'd prefer something like "filterMember". filterMember is to (filter . flip member) as concatMap is to (concat . map). That's not perfectly consistent due to the flip, but I think it's close enough to motivate the name. On Thu, Jul 14, 2016, 5:39 AM Andreas Abel wrote: > +1. > > On 14.07.2016 06:45, David Feuer wrote: > > Cale Gibbard proposes the following: > > > > Data.IntMap.restriction :: IntSet -> IntMap a -> IntMap a > > Data.Map.restriction :: Ord k => Set k -> Map k a -> Map k a > > > > In each case, the map is filtered to contain only the keys that are > > also found in the set. This can be implemented efficiently using a > > slightly stripped-down version of Data.Map.intersection. > > > > David Feuer > > _______________________________________________ > > 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://www2.tcs.ifi.lmu.de/~abel/ > _______________________________________________ > 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 mail at joachim-breitner.de Thu Jul 14 13:25:48 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 14 Jul 2016 15:25:48 +0200 Subject: Proposal: Add `restriction` to Data.Map and Data.IntMap In-Reply-To: References: Message-ID: <1468502748.3310.29.camel@joachim-breitner.de> Hi, Am Donnerstag, den 14.07.2016, 00:45 -0400 schrieb David Feuer: > Data.IntMap.restriction :: IntSet -> IntMap a -> IntMap a > Data.Map.restriction :: Ord k => Set k -> Map k a -> Map k a > > In each case, the map is filtered to contain only the keys that are > also found in the set. This can be implemented efficiently using a > slightly stripped-down version of Data.Map.intersection. +1 I believe I needed that in the past. 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: 819 bytes Desc: This is a digitally signed message part URL: From ivan.miljenovic at gmail.com Thu Jul 14 13:36:34 2016 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Thu, 14 Jul 2016 23:36:34 +1000 Subject: Proposal: Add `restriction` to Data.Map and Data.IntMap In-Reply-To: References: <57875DB8.8040505@chalmers.se> Message-ID: On 14 July 2016 at 22:45, Jake McArthur wrote: > I like the function, but I'd like to bikeshed a bit. The name "restriction" > seems confusing to me, or at least I don't understand the etymology. As of > now I'd prefer something like "filterMember". filterMember is to (filter . > flip member) as concatMap is to (concat . map). That's not perfectly > consistent due to the flip, but I think it's close enough to motivate the > name. More possible bikeshed colours: * intersectionWith/setIntersection to reflect the similarity with the existing intersection functions * restrictTo (which may fit better with the proposed argument order than the ones above) If we keep this argument order, then I think a name similar to restriction as originally proposed makes more sense than an intersection one (as the arguments are flipped compared to the other similarly named functions). > > > On Thu, Jul 14, 2016, 5:39 AM Andreas Abel wrote: >> >> +1. >> >> On 14.07.2016 06:45, David Feuer wrote: >> > Cale Gibbard proposes the following: >> > >> > Data.IntMap.restriction :: IntSet -> IntMap a -> IntMap a >> > Data.Map.restriction :: Ord k => Set k -> Map k a -> Map k a >> > >> > In each case, the map is filtered to contain only the keys that are >> > also found in the set. This can be implemented efficiently using a >> > slightly stripped-down version of Data.Map.intersection. >> > >> > David Feuer >> > _______________________________________________ >> > 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://www2.tcs.ifi.lmu.de/~abel/ >> _______________________________________________ >> 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 > -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From ekmett at gmail.com Thu Jul 14 13:39:52 2016 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 14 Jul 2016 09:39:52 -0400 Subject: Proposal: Add `restriction` to Data.Map and Data.IntMap In-Reply-To: References: <57875DB8.8040505@chalmers.se> Message-ID: +1 on the functionality, not a fan of the name. Bikeshed color: intersectionWithSet? -Edward On Thu, Jul 14, 2016 at 9:36 AM, Ivan Lazar Miljenovic < ivan.miljenovic at gmail.com> wrote: > On 14 July 2016 at 22:45, Jake McArthur wrote: > > I like the function, but I'd like to bikeshed a bit. The name > "restriction" > > seems confusing to me, or at least I don't understand the etymology. As > of > > now I'd prefer something like "filterMember". filterMember is to (filter > . > > flip member) as concatMap is to (concat . map). That's not perfectly > > consistent due to the flip, but I think it's close enough to motivate the > > name. > > More possible bikeshed colours: > > * intersectionWith/setIntersection to reflect the similarity with the > existing intersection functions > > * restrictTo (which may fit better with the proposed argument order > than the ones above) > > If we keep this argument order, then I think a name similar to > restriction as originally proposed makes more sense than an > intersection one (as the arguments are flipped compared to the other > similarly named functions). > > > > > > > On Thu, Jul 14, 2016, 5:39 AM Andreas Abel wrote: > >> > >> +1. > >> > >> On 14.07.2016 06:45, David Feuer wrote: > >> > Cale Gibbard proposes the following: > >> > > >> > Data.IntMap.restriction :: IntSet -> IntMap a -> IntMap a > >> > Data.Map.restriction :: Ord k => Set k -> Map k a -> Map k a > >> > > >> > In each case, the map is filtered to contain only the keys that are > >> > also found in the set. This can be implemented efficiently using a > >> > slightly stripped-down version of Data.Map.intersection. > >> > > >> > David Feuer > >> > _______________________________________________ > >> > 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://www2.tcs.ifi.lmu.de/~abel/ > >> _______________________________________________ > >> 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 > > > > > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic at gmail.com > http://IvanMiljenovic.wordpress.com > _______________________________________________ > 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 Thu Jul 14 15:01:14 2016 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu, 14 Jul 2016 08:01:14 -0700 Subject: Proposal: Add `restriction` to Data.Map and Data.IntMap In-Reply-To: References: <57875DB8.8040505@chalmers.se> Message-ID: I've also needed this in the past, so +1. I think the bike-shed should be colored: intersectKeys or restrictKeys -Iavor On Thu, Jul 14, 2016 at 6:39 AM, Edward Kmett wrote: > +1 on the functionality, not a fan of the name. > > Bikeshed color: intersectionWithSet? > > -Edward > > On Thu, Jul 14, 2016 at 9:36 AM, Ivan Lazar Miljenovic < > ivan.miljenovic at gmail.com> wrote: > >> On 14 July 2016 at 22:45, Jake McArthur wrote: >> > I like the function, but I'd like to bikeshed a bit. The name >> "restriction" >> > seems confusing to me, or at least I don't understand the etymology. As >> of >> > now I'd prefer something like "filterMember". filterMember is to >> (filter . >> > flip member) as concatMap is to (concat . map). That's not perfectly >> > consistent due to the flip, but I think it's close enough to motivate >> the >> > name. >> >> More possible bikeshed colours: >> >> * intersectionWith/setIntersection to reflect the similarity with the >> existing intersection functions >> >> * restrictTo (which may fit better with the proposed argument order >> than the ones above) >> >> If we keep this argument order, then I think a name similar to >> restriction as originally proposed makes more sense than an >> intersection one (as the arguments are flipped compared to the other >> similarly named functions). >> >> > >> > >> > On Thu, Jul 14, 2016, 5:39 AM Andreas Abel wrote: >> >> >> >> +1. >> >> >> >> On 14.07.2016 06:45, David Feuer wrote: >> >> > Cale Gibbard proposes the following: >> >> > >> >> > Data.IntMap.restriction :: IntSet -> IntMap a -> IntMap a >> >> > Data.Map.restriction :: Ord k => Set k -> Map k a -> Map k a >> >> > >> >> > In each case, the map is filtered to contain only the keys that are >> >> > also found in the set. This can be implemented efficiently using a >> >> > slightly stripped-down version of Data.Map.intersection. >> >> > >> >> > David Feuer >> >> > _______________________________________________ >> >> > 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://www2.tcs.ifi.lmu.de/~abel/ >> >> _______________________________________________ >> >> 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 >> > >> >> >> >> -- >> Ivan Lazar Miljenovic >> Ivan.Miljenovic at gmail.com >> http://IvanMiljenovic.wordpress.com >> _______________________________________________ >> 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 alois.cochard at gmail.com Thu Jul 14 15:24:48 2016 From: alois.cochard at gmail.com (=?UTF-8?Q?Alo=C3=AFs_Cochard?=) Date: Thu, 14 Jul 2016 17:24:48 +0200 Subject: Proposal: Add `restriction` to Data.Map and Data.IntMap In-Reply-To: References: <57875DB8.8040505@chalmers.se> Message-ID: +1, I wanted it in the past. Color: intesectionWith, or variant. not a fan of `restriction`. On 14 July 2016 at 15:39, Edward Kmett wrote: > +1 on the functionality, not a fan of the name. > > Bikeshed color: intersectionWithSet? > > -Edward > > On Thu, Jul 14, 2016 at 9:36 AM, Ivan Lazar Miljenovic < > ivan.miljenovic at gmail.com> wrote: > >> On 14 July 2016 at 22:45, Jake McArthur wrote: >> > I like the function, but I'd like to bikeshed a bit. The name >> "restriction" >> > seems confusing to me, or at least I don't understand the etymology. As >> of >> > now I'd prefer something like "filterMember". filterMember is to >> (filter . >> > flip member) as concatMap is to (concat . map). That's not perfectly >> > consistent due to the flip, but I think it's close enough to motivate >> the >> > name. >> >> More possible bikeshed colours: >> >> * intersectionWith/setIntersection to reflect the similarity with the >> existing intersection functions >> >> * restrictTo (which may fit better with the proposed argument order >> than the ones above) >> >> If we keep this argument order, then I think a name similar to >> restriction as originally proposed makes more sense than an >> intersection one (as the arguments are flipped compared to the other >> similarly named functions). >> >> > >> > >> > On Thu, Jul 14, 2016, 5:39 AM Andreas Abel wrote: >> >> >> >> +1. >> >> >> >> On 14.07.2016 06:45, David Feuer wrote: >> >> > Cale Gibbard proposes the following: >> >> > >> >> > Data.IntMap.restriction :: IntSet -> IntMap a -> IntMap a >> >> > Data.Map.restriction :: Ord k => Set k -> Map k a -> Map k a >> >> > >> >> > In each case, the map is filtered to contain only the keys that are >> >> > also found in the set. This can be implemented efficiently using a >> >> > slightly stripped-down version of Data.Map.intersection. >> >> > >> >> > David Feuer >> >> > _______________________________________________ >> >> > 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://www2.tcs.ifi.lmu.de/~abel/ >> >> _______________________________________________ >> >> 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 >> > >> >> >> >> -- >> Ivan Lazar Miljenovic >> Ivan.Miljenovic at gmail.com >> http://IvanMiljenovic.wordpress.com >> _______________________________________________ >> 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 > > -- *Λ\oïs* http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell at benmachine.co.uk Thu Jul 14 15:33:35 2016 From: haskell at benmachine.co.uk (Ben Millwood) Date: Thu, 14 Jul 2016 23:33:35 +0800 Subject: Proposal for containers: Add 'lookup' function to Data.Set In-Reply-To: References: <5EEE6504-A5F7-4D56-AD1B-1D289196E37B@gmail.com> Message-ID: <20160714153334.GA1653@euler.local> I agree with Henning, and moreover with wren's point that Data.Set is an often-unsatisfactory data structure for interning in general. Map can do the job more obviously and more comprehensively, at the cost of a few more pointers -- and when has Haskell ever been about trading clarity for fewer pointers? I don't think I'll formally vote, since I haven't written any Haskell in months, but I think the addition of this at-first-glance seemingly-useless function adds surprise and a little bit of headscratching to the user interface as a whole, to the extent that I feel like it has a "weirdness cost" even if most users can just ignore it. It also complicates (in my mind) the semantic story of Data.Set, from something purely about a collection of elements and a membership test to something which has specific opinions on which of two notionally "equal" things are most appropriate in a given situation. I think the cost of turning Data.Set from a simple thing into a complicated thing is a subtle one that should not totally be overlooked -- API simplicity is a virtue in itself. Add to that Henning and wren's evidence, which I interpret as saying that this function isn't quite the *perfect* tool for seemingly *any* job, and it doesn't seem worth the cognitive / maintenance cost to me. (I perhaps do not expect these considerations to be very strong or very important, but I think it would be unwise to ignore them altogether.) On Tue, Jun 28, 2016 at 11:19:16AM +0200, Henning Thielemann wrote: > >On Mon, 27 Jun 2016, Nicolas Godbout wrote: > >>Example use case: In a parser, the memory footprint can be reduced by collapsing >>all equal strings to a single instance of each string. To achieve this, one needs >>a way to get a previously seen string (internally, a pointer) equal to a newly >>parsed string. Amazingly, this is very difficult with the current "containers" library interface. >>One current option is to use a Map instead, e.g., 'Map String String' >>which stores twice as many pointers as necessary. > >I think I'd prefer the (Map String String) variant to an obscure Set >lookup function. I wonder whether you will later use the Map anyway, >as the compiler grows and you need to attach more data to tokens. In >order to make your intent clearer you might define > > newtype SharedToken = SharedToken String > >and use (Map String SharedToken). >_______________________________________________ >Libraries mailing list >Libraries at haskell.org >http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From amindfv at gmail.com Thu Jul 14 15:41:02 2016 From: amindfv at gmail.com (amindfv at gmail.com) Date: Thu, 14 Jul 2016 11:41:02 -0400 Subject: Proposal: Add `restriction` to Data.Map and Data.IntMap In-Reply-To: References: <57875DB8.8040505@chalmers.se> Message-ID: +1 to the function, +1 to 'restrictKeys' or 'intersectKeys' Tom > El 14 jul 2016, a las 11:01, Iavor Diatchki escribió: > > I've also needed this in the past, so +1. > > I think the bike-shed should be colored: intersectKeys or restrictKeys > > -Iavor > >> On Thu, Jul 14, 2016 at 6:39 AM, Edward Kmett wrote: >> +1 on the functionality, not a fan of the name. >> >> Bikeshed color: intersectionWithSet? >> >> -Edward >> >>> On Thu, Jul 14, 2016 at 9:36 AM, Ivan Lazar Miljenovic wrote: >>> On 14 July 2016 at 22:45, Jake McArthur wrote: >>> > I like the function, but I'd like to bikeshed a bit. The name "restriction" >>> > seems confusing to me, or at least I don't understand the etymology. As of >>> > now I'd prefer something like "filterMember". filterMember is to (filter . >>> > flip member) as concatMap is to (concat . map). That's not perfectly >>> > consistent due to the flip, but I think it's close enough to motivate the >>> > name. >>> >>> More possible bikeshed colours: >>> >>> * intersectionWith/setIntersection to reflect the similarity with the >>> existing intersection functions >>> >>> * restrictTo (which may fit better with the proposed argument order >>> than the ones above) >>> >>> If we keep this argument order, then I think a name similar to >>> restriction as originally proposed makes more sense than an >>> intersection one (as the arguments are flipped compared to the other >>> similarly named functions). >>> >>> > >>> > >>> > On Thu, Jul 14, 2016, 5:39 AM Andreas Abel wrote: >>> >> >>> >> +1. >>> >> >>> >> On 14.07.2016 06:45, David Feuer wrote: >>> >> > Cale Gibbard proposes the following: >>> >> > >>> >> > Data.IntMap.restriction :: IntSet -> IntMap a -> IntMap a >>> >> > Data.Map.restriction :: Ord k => Set k -> Map k a -> Map k a >>> >> > >>> >> > In each case, the map is filtered to contain only the keys that are >>> >> > also found in the set. This can be implemented efficiently using a >>> >> > slightly stripped-down version of Data.Map.intersection. >>> >> > >>> >> > David Feuer >>> >> > _______________________________________________ >>> >> > 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://www2.tcs.ifi.lmu.de/~abel/ >>> >> _______________________________________________ >>> >> 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 >>> > >>> >>> >>> >>> -- >>> Ivan Lazar Miljenovic >>> Ivan.Miljenovic at gmail.com >>> http://IvanMiljenovic.wordpress.com >>> _______________________________________________ >>> 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 abela at chalmers.se Thu Jul 14 15:48:28 2016 From: abela at chalmers.se (Andreas Abel) Date: Thu, 14 Jul 2016 17:48:28 +0200 Subject: Proposal: Add `restriction` to Data.Map and Data.IntMap In-Reply-To: References: <57875DB8.8040505@chalmers.se> Message-ID: <5787B44C.4030401@chalmers.se> Restricting the domain of a function is common terminology in maths. I like the original name 'restrict' or 'restrictTo' or 'restrictKeys'. Intersection is a symmetric operation, so that name is less suitable, imho. On 14.07.2016 17:41, amindfv at gmail.com wrote: > +1 to the function, +1 to 'restrictKeys' or 'intersectKeys' > > Tom > > > El 14 jul 2016, a las 11:01, Iavor Diatchki > escribió: > >> I've also needed this in the past, so +1. >> >> I think the bike-shed should be colored: intersectKeys or restrictKeys >> >> -Iavor >> >> On Thu, Jul 14, 2016 at 6:39 AM, Edward Kmett > > wrote: >> >> +1 on the functionality, not a fan of the name. >> >> Bikeshed color: intersectionWithSet? >> >> -Edward >> >> On Thu, Jul 14, 2016 at 9:36 AM, Ivan Lazar Miljenovic >> > wrote: >> >> On 14 July 2016 at 22:45, Jake McArthur >> > wrote: >> > I like the function, but I'd like to bikeshed a bit. The name "restriction" >> > seems confusing to me, or at least I don't understand the etymology. As of >> > now I'd prefer something like "filterMember". filterMember is to (filter . >> > flip member) as concatMap is to (concat . map). That's not perfectly >> > consistent due to the flip, but I think it's close enough to motivate the >> > name. >> >> More possible bikeshed colours: >> >> * intersectionWith/setIntersection to reflect the similarity >> with the >> existing intersection functions >> >> * restrictTo (which may fit better with the proposed argument >> order >> than the ones above) >> >> If we keep this argument order, then I think a name similar to >> restriction as originally proposed makes more sense than an >> intersection one (as the arguments are flipped compared to the >> other >> similarly named functions). >> >> > >> > >> > On Thu, Jul 14, 2016, 5:39 AM Andreas Abel >> > wrote: >> >> >> >> +1. >> >> >> >> On 14.07.2016 06:45, David Feuer wrote: >> >> > Cale Gibbard proposes the following: >> >> > >> >> > Data.IntMap.restriction :: IntSet -> IntMap a -> IntMap a >> >> > Data.Map.restriction :: Ord k => Set k -> Map k a -> Map k a >> >> > >> >> > In each case, the map is filtered to contain only the >> keys that are >> >> > also found in the set. This can be implemented >> efficiently using a >> >> > slightly stripped-down version of Data.Map.intersection. >> >> > >> >> > David Feuer >> >> > _______________________________________________ >> >> > 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://www2.tcs.ifi.lmu.de/~abel/ >> >> _______________________________________________ >> >> 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 >> > >> >> >> >> -- >> Ivan Lazar Miljenovic >> Ivan.Miljenovic at gmail.com >> http://IvanMiljenovic.wordpress.com >> _______________________________________________ >> 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 -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www2.tcs.ifi.lmu.de/~abel/ From david.feuer at gmail.com Thu Jul 14 15:52:20 2016 From: david.feuer at gmail.com (David Feuer) Date: Thu, 14 Jul 2016 11:52:20 -0400 Subject: Proposal: Add Foldable helper to Control.DeepSeq In-Reply-To: References: Message-ID: I guess these are equivalent to the simpler expressions rnfLTR = foldl' (const rnf) () rnfRTL = foldr' (\x _ -> rnf x) () On Jul 13, 2016 11:16 PM, "David Feuer" wrote: > As I describe in https://github.com/haskell/deepseq/issues/17 it is > possible to implement an NFData instance for any Foldable type, and we > can offer a function to help do that: > > data Unit = Unit > > instance Monoid Unit where > mempty = Unit > Unit `mappend` Unit = Unit -- strict in both arguments, unlike () > > rnfFoldable :: (Foldable f, NFData a) => f a -> () > rnfFoldable xs = foldMap (\x -> rnf x `seq` Unit) xs `seq` () > > This could be used like so: > > instance NFData a => NFData (F a) where > rnf = rnfFoldable > > This version forces from left to right. It would be possible to offer > another version that forces from right to left: > > data Unit2 = Unit2 > > instance Monoid Unit2 where > mempty = Unit2 > x `mappend` Unit2 = x `seq` Unit2 > > rnfFoldableRTL :: (Foldable f, NFData a) => f a -> () > rnfFoldableRTL xs = foldMap (\x -> rnf x `seq` Unit2) xs `seq` () > -------------- next part -------------- An HTML attachment was scrubbed... URL: From R.Paterson at city.ac.uk Thu Jul 14 15:54:46 2016 From: R.Paterson at city.ac.uk (Ross Paterson) Date: Thu, 14 Jul 2016 16:54:46 +0100 Subject: Proposal: Add `restriction` to Data.Map and Data.IntMap In-Reply-To: References: Message-ID: <20160714155446.GA11038@city.ac.uk> On Thu, Jul 14, 2016 at 12:45:27AM -0400, David Feuer wrote: > Cale Gibbard proposes the following: > > Data.IntMap.restriction :: IntSet -> IntMap a -> IntMap a > Data.Map.restriction :: Ord k => Set k -> Map k a -> Map k a > > In each case, the map is filtered to contain only the keys that are > also found in the set. This can be implemented efficiently using a > slightly stripped-down version of Data.Map.intersection. One might also want the counterpart of Data.Map.difference for similar reasons. From haskell at benmachine.co.uk Thu Jul 14 15:56:22 2016 From: haskell at benmachine.co.uk (Ben Millwood) Date: Thu, 14 Jul 2016 23:56:22 +0800 Subject: Discussion: add more idiomatic versions of catchJust and/or handleJust In-Reply-To: References: <5786983C.7000103@ifi.lmu.de> Message-ID: <20160714155621.GB1653@euler.local> Am I right in thinking that `catch` is equivalent to `catchJust fromException`? Perhaps the intention is that if you have an implementation of `fromException` but haven't defined an instance of `Exception` for whatever reason, you can use `catchJust` directly? Or if you have a slight variant of `fromException` that isn't quite worth its own typeclass instance? Analogously to `sortBy` vs. `sort`, for example. I have no particular vote on the proposal and do not intend the above as a defence of `catchJust`, just a possible perspective on it. On Wed, Jul 13, 2016 at 02:23:04PM -0700, Theodore Lief Gannon wrote: >+1 on catchMaybe from this corner of the peanut gallery, FWIW. It feels far >more idiomatic, and provides the same power with fewer moving parts. >On Jul 13, 2016 1:14 PM, "David Feuer" wrote: > >> I hate having to make arbitrary choices when writing code. With >> `catchJust`, I have to decide what to calculate in the selector and >> what to calculate in the handler. As far as I can tell, there's never >> any reason to leave any calculation for the handler. >> >> I don't think the `Maybe (IO a)` type is nearly as hard to think about >> as exceptions themselves are. The handler either provides a recovery >> action or it doesn't. The catchMaybe signature strikes me, personally, >> as easier to understand, because I don't need to use parametricity to >> string the pieces together. >> >> On Wed, Jul 13, 2016 at 3:36 PM, Andreas Abel >> wrote: >> > I can only guess why catchJust was designed like it is. A type like >> > >> > b -> Maybe (IO a) >> > >> > is not as intuitive as the types >> > >> > e -> Maybe b >> > -- ^ if you do not understand this, get back to Haskell school! >> > >> > b -> IO a >> > -- ^ a continuation, we know this from >>= and friends >> > >> > A type like Maybe (IO a) is more unusual, requires more thinking. >> > >> > +-0. I have no opinion on what is better. >> > >> > >> > On 12.07.2016 02:23, David Feuer wrote: >> >> >> >> The catchJust and handleJust functions seem a bit weird and unidiomatic. >> >> >> >> catchJust >> >> :: Exception e >> >> => (e -> Maybe b) -- ^ Predicate to select exceptions >> >> -> IO a -- ^ Computation to run >> >> -> (b -> IO a) -- ^ Handler >> >> -> IO a >> >> catchJust p a handler = catch a handler' >> >> where handler' e = case p e of >> >> Nothing -> throwIO e >> >> Just b -> handler b >> >> >> >> This takes two functions and then puts them together. I would think the >> >> more natural API would be >> >> >> >> catchMaybe :: Exception e => IO a -> (e -> Maybe (IO a)) -> IO a >> >> catchMaybe m handler = catch m handler' where >> >> handler' e = fromMaybe (throwIO e) (handler e) >> >> >> >> This is exactly as powerful as catchJust: >> >> >> >> catchMaybe m handler = catchJust handler m id >> >> catchJust p m handler = catchMaybe m $ fmap handler . p >> >> >> >> But catchMaybe doesn't enforce the arbitrary separation between >> >> "selection" and "handling". >> >> >> >> >> >> >> >> _______________________________________________ >> >> 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://www2.tcs.ifi.lmu.de/~abel/ >> _______________________________________________ >> 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 david.feuer at gmail.com Thu Jul 14 16:02:51 2016 From: david.feuer at gmail.com (David Feuer) Date: Thu, 14 Jul 2016 12:02:51 -0400 Subject: Proposal: Add `restriction` to Data.Map and Data.IntMap In-Reply-To: <20160714155446.GA11038@city.ac.uk> References: <20160714155446.GA11038@city.ac.uk> Message-ID: If you name it, it will come! On Jul 14, 2016 11:55 AM, "Ross Paterson" wrote: > On Thu, Jul 14, 2016 at 12:45:27AM -0400, David Feuer wrote: > > Cale Gibbard proposes the following: > > > > Data.IntMap.restriction :: IntSet -> IntMap a -> IntMap a > > Data.Map.restriction :: Ord k => Set k -> Map k a -> Map k a > > > > In each case, the map is filtered to contain only the keys that are > > also found in the set. This can be implemented efficiently using a > > slightly stripped-down version of Data.Map.intersection. > > One might also want the counterpart of Data.Map.difference for similar > reasons. > _______________________________________________ > 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 dave at zednenem.com Thu Jul 14 16:11:31 2016 From: dave at zednenem.com (David Menendez) Date: Thu, 14 Jul 2016 12:11:31 -0400 Subject: Discussion: add more idiomatic versions of catchJust and/or handleJust In-Reply-To: References: Message-ID: On Mon, Jul 11, 2016 at 8:23 PM, David Feuer wrote: > The catchJust and handleJust functions seem a bit weird and unidiomatic. > > catchJust > :: Exception e > => (e -> Maybe b) -- ^ Predicate to select exceptions > -> IO a -- ^ Computation to run > -> (b -> IO a) -- ^ Handler > -> IO a > catchJust p a handler = catch a handler' > where handler' e = case p e of > Nothing -> throwIO e > Just b -> handler b > > This takes two functions and then puts them together. I would think the > more natural API would be > > catchMaybe :: Exception e => IO a -> (e -> Maybe (IO a)) -> IO a > catchMaybe m handler = catch m handler' where > handler' e = fromMaybe (throwIO e) (handler e) > > This is exactly as powerful as catchJust: > > catchMaybe m handler = catchJust handler m id > catchJust p m handler = catchMaybe m $ fmap handler . p > > But catchMaybe doesn't enforce the arbitrary separation between > "selection" and "handling”. > I wouldn’t call it an arbitrary separation. I imagine that the separation is deliberate, because you will frequently want to catch the same set of exceptions, but want to do different things in different contexts. With the current API, you can write a selector like “fileNotFound” and re-use it with multiple handlers. In constrast, with a unified seletor/handler you have to write the same code to filter the exceptions you want with every handler which deals with them. You might as well just use catch. -- Dave Menendez -------------- next part -------------- An HTML attachment was scrubbed... URL: From qdunkan at gmail.com Thu Jul 14 16:13:12 2016 From: qdunkan at gmail.com (Evan Laforge) Date: Thu, 14 Jul 2016 09:13:12 -0700 Subject: Proposal: Add `restriction` to Data.Map and Data.IntMap In-Reply-To: References: <57875DB8.8040505@chalmers.se> Message-ID: On Thu, Jul 14, 2016 at 8:01 AM, Iavor Diatchki wrote: > I've also needed this in the past, so +1. > > I think the bike-shed should be colored: intersectKeys or restrictKeys +1 for intersectKeys. I already have to look up Data.Map haddock constantly (e.g. alter vs. adjust), but intersectKeys is nicely self descriptive. From R.Paterson at city.ac.uk Thu Jul 14 16:17:48 2016 From: R.Paterson at city.ac.uk (Ross Paterson) Date: Thu, 14 Jul 2016 17:17:48 +0100 Subject: Proposal: Add `restriction` to Data.Map and Data.IntMap In-Reply-To: References: <20160714155446.GA11038@city.ac.uk> Message-ID: <20160714161748.GA11763@city.ac.uk> On Thu, Jul 14, 2016 at 12:02:51PM -0400, David Feuer wrote: > On Jul 14, 2016 11:55 AM, "Ross Paterson" wrote: > One might also want the counterpart of Data.Map.difference for similar > reasons. > > If you name it, it will come! Whatever they're called, putting the set argument second for both functions would match Data.Map.interection and Data.Map.difference, which would help. From daniel.trstenjak at gmail.com Thu Jul 14 16:36:03 2016 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Thu, 14 Jul 2016 18:36:03 +0200 Subject: Proposal: Add `restriction` to Data.Map and Data.IntMap In-Reply-To: References: <20160714155446.GA11038@city.ac.uk> Message-ID: <20160714163603.GA28546@octa> On Thu, Jul 14, 2016 at 12:02:51PM -0400, David Feuer wrote: > If you name it, it will come! intersectKeys and differentiateKeys or intersectionWithSet and differenceWithSet or ;) intersectionOfKeys and differenceOfKeys Greetings, Daniel From vagarenko at gmail.com Thu Jul 14 16:54:50 2016 From: vagarenko at gmail.com (Alexey Vagarenko) Date: Thu, 14 Jul 2016 21:54:50 +0500 Subject: Proposal: Add `restriction` to Data.Map and Data.IntMap In-Reply-To: <20160714163603.GA28546@octa> References: <20160714155446.GA11038@city.ac.uk> <20160714163603.GA28546@octa> Message-ID: How about `keepKeys`? 2016-07-14 21:36 GMT+05:00 Daniel Trstenjak : > On Thu, Jul 14, 2016 at 12:02:51PM -0400, David Feuer wrote: > > If you name it, it will come! > > intersectKeys and differentiateKeys > > or > > intersectionWithSet and differenceWithSet > > or ;) > > intersectionOfKeys and differenceOfKeys > > > Greetings, > Daniel > _______________________________________________ > 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 ollie at ocharles.org.uk Thu Jul 14 16:56:21 2016 From: ollie at ocharles.org.uk (Oliver Charles) Date: Thu, 14 Jul 2016 16:56:21 +0000 Subject: Discussion: add more idiomatic versions of catchJust and/or handleJust In-Reply-To: References: Message-ID: On Tue, 12 Jul 2016, 1:23 a.m. David Feuer, wrote: > The catchJust and handleJust functions seem a bit weird and unidiomatic. > > catchJust > :: Exception e > => (e -> Maybe b) -- ^ Predicate to select exceptions > -> IO a -- ^ Computation to run > -> (b -> IO a) -- ^ Handler > -> IO a > catchJust p a handler = catch a handler' > where handler' e = case p e of > Nothing -> throwIO e > Just b -> handler b > > This takes two functions and then puts them together. I would think the > more natural API would be > > catchMaybe :: Exception e => IO a -> (e -> Maybe (IO a)) -> IO a > catchMaybe m handler = catch m handler' where > handler' e = fromMaybe (throwIO e) (handler e) > A point don't feel super strongly about, but feel I should raise, is that Nothing seems to be somewhat confusing. catchJust (\FileNotFound -> Nothing) seems to suggest that if FileNotFound occurs then nothing will happen, that is - the exception is ignored. However, that is not the case, rather than Nothing happening something certainly happens - an exception is (re)thrown! Whether or not this confusion is likely to happen in practice I don't know, but it suggests a type isomorphic to Maybe is a better fit. Ollie -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Thu Jul 14 17:10:10 2016 From: david.feuer at gmail.com (David Feuer) Date: Thu, 14 Jul 2016 13:10:10 -0400 Subject: Discussion: add more idiomatic versions of catchJust and/or handleJust In-Reply-To: References: Message-ID: I expect it'd be more common to use something like catchMaybe m $ \e -> guard (isEOFException e) >> return "" catchJust only makes sense if you not only need the same set of exceptions, but also the same non-trivial calculation based on the exception, for multiple handlers. A hypothetical catchOnly taking a Boolean predicate would make more sense for the case you describe. On Jul 14, 2016 12:11 PM, "David Menendez" wrote: > On Mon, Jul 11, 2016 at 8:23 PM, David Feuer > wrote: > >> The catchJust and handleJust functions seem a bit weird and unidiomatic. >> >> catchJust >> :: Exception e >> => (e -> Maybe b) -- ^ Predicate to select exceptions >> -> IO a -- ^ Computation to run >> -> (b -> IO a) -- ^ Handler >> -> IO a >> catchJust p a handler = catch a handler' >> where handler' e = case p e of >> Nothing -> throwIO e >> Just b -> handler b >> >> This takes two functions and then puts them together. I would think the >> more natural API would be >> >> catchMaybe :: Exception e => IO a -> (e -> Maybe (IO a)) -> IO a >> catchMaybe m handler = catch m handler' where >> handler' e = fromMaybe (throwIO e) (handler e) >> >> This is exactly as powerful as catchJust: >> >> catchMaybe m handler = catchJust handler m id >> catchJust p m handler = catchMaybe m $ fmap handler . p >> >> But catchMaybe doesn't enforce the arbitrary separation between >> "selection" and "handling”. >> > I wouldn’t call it an arbitrary separation. I imagine that the separation > is deliberate, because you will frequently want to catch the same set of > exceptions, but want to do different things in different contexts. With the > current API, you can write a selector like “fileNotFound” and re-use it > with multiple handlers. > > In constrast, with a unified seletor/handler you have to write the same > code to filter the exceptions you want with every handler which deals with > them. You might as well just use catch. > > -- > Dave Menendez > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Thu Jul 14 17:12:39 2016 From: david.feuer at gmail.com (David Feuer) Date: Thu, 14 Jul 2016 13:12:39 -0400 Subject: Discussion: add more idiomatic versions of catchJust and/or handleJust In-Reply-To: References: Message-ID: That makes sense, I guess. Something like data Handle a = Rethrow | Catch (IO a) I suppose? My names are awful though. On Jul 14, 2016 12:56 PM, "Oliver Charles" wrote: > > > On Tue, 12 Jul 2016, 1:23 a.m. David Feuer, wrote: > >> The catchJust and handleJust functions seem a bit weird and unidiomatic. >> >> catchJust >> :: Exception e >> => (e -> Maybe b) -- ^ Predicate to select exceptions >> -> IO a -- ^ Computation to run >> -> (b -> IO a) -- ^ Handler >> -> IO a >> catchJust p a handler = catch a handler' >> where handler' e = case p e of >> Nothing -> throwIO e >> Just b -> handler b >> >> This takes two functions and then puts them together. I would think the >> more natural API would be >> >> catchMaybe :: Exception e => IO a -> (e -> Maybe (IO a)) -> IO a >> catchMaybe m handler = catch m handler' where >> handler' e = fromMaybe (throwIO e) (handler e) >> > A point don't feel super strongly about, but feel I should raise, is that > Nothing seems to be somewhat confusing. catchJust (\FileNotFound -> > Nothing) seems to suggest that if FileNotFound occurs then nothing will > happen, that is - the exception is ignored. However, that is not the case, > rather than Nothing happening something certainly happens - an exception is > (re)thrown! > > Whether or not this confusion is likely to happen in practice I don't > know, but it suggests a type isomorphic to Maybe is a better fit. > > Ollie > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.abel at ifi.lmu.de Thu Jul 14 17:53:12 2016 From: andreas.abel at ifi.lmu.de (Andreas Abel) Date: Thu, 14 Jul 2016 19:53:12 +0200 Subject: Discussion: add more idiomatic versions of catchJust and/or handleJust In-Reply-To: References: Message-ID: <5787D188.2080703@ifi.lmu.de> Maybe rather data Handle a = Rethrow | Handle (IO a) !? On 14.07.2016 19:12, David Feuer wrote: > That makes sense, I guess. Something like > > data Handle a = Rethrow | Catch (IO a) > > I suppose? My names are awful though. > > > On Jul 14, 2016 12:56 PM, "Oliver Charles" > wrote: > > > > On Tue, 12 Jul 2016, 1:23 a.m. David Feuer, > wrote: > > The catchJust and handleJust functions seem a bit weird and > unidiomatic. > > catchJust > :: Exception e > => (e -> Maybe b) -- ^ Predicate to select > exceptions > -> IO a -- ^ Computation to run > -> (b -> IO a) -- ^ Handler > -> IO a > catchJust p a handler = catch a handler' > where handler' e = case p e of > Nothing -> throwIO e > Just b -> handler b > > This takes two functions and then puts them together. I would > think the more natural API would be > > catchMaybe :: Exception e => IO a -> (e -> Maybe (IO a)) -> IO a > catchMaybe m handler = catch m handler' where > handler' e = fromMaybe (throwIO e) (handler e) > > A point don't feel super strongly about, but feel I should raise, is > that Nothing seems to be somewhat confusing. catchJust > (\FileNotFound -> Nothing) seems to suggest that if FileNotFound > occurs then nothing will happen, that is - the exception is ignored. > However, that is not the case, rather than Nothing happening > something certainly happens - an exception is (re)thrown! > > Whether or not this confusion is likely to happen in practice I > don't know, but it suggests a type isomorphic to Maybe is a better fit. > > Ollie > > > > _______________________________________________ > 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://www2.tcs.ifi.lmu.de/~abel/ From spam at scientician.net Thu Jul 14 18:00:47 2016 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 14 Jul 2016 20:00:47 +0200 Subject: Discussion: add more idiomatic versions of catchJust and/or handleJust In-Reply-To: <5787D188.2080703@ifi.lmu.de> References: <5787D188.2080703@ifi.lmu.de> Message-ID: On 07/14/2016 07:53 PM, Andreas Abel wrote: > Maybe rather > > data Handle a = Rethrow | Handle (IO a) > +1 From oleg.grenrus at iki.fi Thu Jul 14 18:06:01 2016 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Thu, 14 Jul 2016 21:06:01 +0300 Subject: Discussion: add more idiomatic versions of catchJust and/or handleJust In-Reply-To: References: Message-ID: Maybe pointing out the obvious, but when used with lens, catchJust approach is handy: — | here catchJust is from `exceptions` though catching :: MonadCatch m => Getting (First a) SomeException a -> m r -> (a -> m r) -> m r catching l = catchJust (preview l) http://hackage.haskell.org/package/lens-4.14/docs/src/Control.Exception.Lens.html#catching +/- 0 on catchMaybe - Oleg > On 12 Jul 2016, at 03:23, David Feuer wrote: > > The catchJust and handleJust functions seem a bit weird and unidiomatic. > > catchJust > :: Exception e > => (e -> Maybe b) -- ^ Predicate to select exceptions > -> IO a -- ^ Computation to run > -> (b -> IO a) -- ^ Handler > -> IO a > catchJust p a handler = catch a handler' > where handler' e = case p e of > Nothing -> throwIO e > Just b -> handler b > > This takes two functions and then puts them together. I would think the more natural API would be > > catchMaybe :: Exception e => IO a -> (e -> Maybe (IO a)) -> IO a > catchMaybe m handler = catch m handler' where > handler' e = fromMaybe (throwIO e) (handler e) > > This is exactly as powerful as catchJust: > > catchMaybe m handler = catchJust handler m id > catchJust p m handler = catchMaybe m $ fmap handler . p > > But catchMaybe doesn't enforce the arbitrary separation between "selection" and "handling". > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From conal at conal.net Thu Jul 14 18:38:52 2016 From: conal at conal.net (Conal Elliott) Date: Thu, 14 Jul 2016 11:38:52 -0700 Subject: Proposal: add liftA4 and liftA5 to match liftM4 and liftM5 In-Reply-To: References: <545C9C17.4000400@chalmers.se> <545CBF4E.2050308@mcmaster.ca> <545E0FA2.5000408@chalmers.se> Message-ID: Any recent thoughts on adding liftA4 and liftA5 to Control.Applicative? On Sat, Nov 8, 2014 at 11:39 AM, Edward Kmett wrote: > We have two competing tensions that have been guiding the work so far, > which is scattered across a few dozen different proposals and patches in > Phab and is alarmingly intricate to detail. > > We've generally been guided by the notion you suggest here. In the wake of > the AMP, the 'M' suffix really comes to mean the minimal set of effects > needed to get the effect. This lets us generalize large numbers of > combinators in Control.Monad (e.g. when/unless/guard) to 'just work' in > more contexts. > > However, we also have to balance this carefully against two other concerns: > > 1.) Not breaking user code silently in undetectable ways. > > This is of course the utmost priority. It guides much of the AMP, > including the 'backwards' direction of most of the dependencies. e.g. The > reality is a large number of folks wrote (*>) = (>>) in their code, so e.g. > if we defined (>>) = (*>), we'd get a large chunk of existing production > code that just turns into infinite loops. We can always do more later as we > find it is safe, but "first do no harm." > > 2.) Not introducing rampant performance regressions. > > David Feuer has been spending untold hours on this, and his work there is > a large part of the source of endless waves of proposals he's been putting > forth. > > Considering `liftM2` as 'redundant' from `liftA2` can be dangerous on this > front. > > The decision of if we can alias liftM3 to liftA3 needs to be at least > *partially* guided by the question of whether the latter is a viable > replacement in practice. I'm not prepared to come down on one side of that > debate without more profiling data. > > Adding liftA4, liftA5 runs afoul of neither of these caveats. Aliasing > liftMn to liftAn is something that *potentially* runs afoul of the > latter, and is something that we don't have to do in a frantic rush. The > world won't end if we play it safe and don't get to it in time for 7.10. > > -Edward > > On Sat, Nov 8, 2014 at 7:42 AM, Andreas Abel wrote: > >> I am a bit alert about this discussion because it seems that we have >> quite different ideas about how the AMP implementation should affect the >> base libraries. >> >> 1. Where can we see and discuss the proposed changes? >> >> Not on https://www.haskell.org/haskellwiki/Functor- >> Applicative-Monad_Proposal >> >> Not on https://ghc.haskell.org/trac/ghc/ticket/9586 >> >> 2. Imho, the reasonable thing is to >> >> rewrite all of F/A/M base functions such that they use the minimal >> F/A/M constraints. >> >> This of course includes >> >> liftM :: (Functor m) => (a -> b) -> m a -> m b >> liftM2 :: (Applicative m) => (a -> b -> c) -> m a -> m b -> m c >> >> and sequence and friends even if the M postfix can then "only explained >> historically" (HT). >> >> One can say "M" stands for "effectful", but the minimal type class to >> realize the effect is chosen from F/A/M. >> >> If we burn bridges, we should do it properly. >> >> Cheers, >> Andreas >> >> >> On 07.11.2014 20:35, Edward Kmett wrote: >> >>> I don't want them for rewriting liftM4 and liftM5, I want them in their >>> own right. >>> >>> It doesn't do anyone any good to just have random asymmetries in the API >>> like that. >>> >>> It just means a user goes to reach for a tool, doesn't find it and >>> flails around. >>> >>> -Edward >>> >>> On Fri, Nov 7, 2014 at 1:37 PM, John Lato >> > wrote: >>> >>> I still don't think it's worth adding liftA4 and liftA5 just so that >>> liftM4+ can be rewritten. >>> >>> Very weakly -0.1 >>> >>> On Fri Nov 07 2014 at 10:24:27 AM David Feuer >> > wrote: >>> >>> Another point: using `liftA` or `liftM`, specialized to the >>> relevant type, may reduce code size in some cases. With f <$> a >>> <*> b <*> c and such, you have to hope that you either get some >>> benefit from the inlining or that CSE is able to save you from >>> the duplication. >>> >>> On Fri, Nov 7, 2014 at 7:47 AM, Jacques Carette >>> > wrote: >>> >>> On 2014-11-07 5:30 AM, Henning Thielemann wrote: >>> >>> >>> On Fri, 7 Nov 2014, Andreas Abel wrote: >>> >>> I hope the same happens for sequence, mapM and the >>> like! >>> >>> sequence :: (Applicative m) => [m a] -> m [a] >>> sequence = foldr (\ x xs -> (:) <$> x <*> xs) >>> (pure []) >>> >>> >>> Actually, this is an example, where liftA2 shows its >>> advantage: >>> >>> sequence = foldr (liftA2 (:)) (pure []) >>> >>> This looks much clearer to me than decoding the mixture >>> of infix and uninfixed infix operators. It simply says, >>> that 'sequence' is like 'id = foldr (:) []' but with >>> everything lifted to an applicative functor. >>> >>> >>> I agree. I have lots of code which looks really clean >>> because I can use liftA2 (and even liftA3) in exactly the >>> way above. Having to eta expand everything obscures the >>> real meat of what is going on. >>> >>> Jacques >>> >>> _________________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://www.haskell.org/__mailman/listinfo/libraries >>> >>> >>> >>> _________________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://www.haskell.org/__mailman/listinfo/libraries >>> >>> >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://www.haskell.org/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://www2.tcs.ifi.lmu.de/~abel/ >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Thu Jul 14 19:07:48 2016 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 14 Jul 2016 15:07:48 -0400 Subject: Proposal: add liftA4 and liftA5 to match liftM4 and liftM5 In-Reply-To: References: <545C9C17.4000400@chalmers.se> <545CBF4E.2050308@mcmaster.ca> <545E0FA2.5000408@chalmers.se> Message-ID: Given the long discussion we've had here, I'll make a call from the standpoint of the CLC and say we'd happily accept a patch that added them. -Edward On Thu, Jul 14, 2016 at 2:38 PM, Conal Elliott wrote: > Any recent thoughts on adding liftA4 and liftA5 to Control.Applicative? > > On Sat, Nov 8, 2014 at 11:39 AM, Edward Kmett wrote: > >> We have two competing tensions that have been guiding the work so far, >> which is scattered across a few dozen different proposals and patches in >> Phab and is alarmingly intricate to detail. >> >> We've generally been guided by the notion you suggest here. In the wake >> of the AMP, the 'M' suffix really comes to mean the minimal set of effects >> needed to get the effect. This lets us generalize large numbers of >> combinators in Control.Monad (e.g. when/unless/guard) to 'just work' in >> more contexts. >> >> However, we also have to balance this carefully against two other >> concerns: >> >> 1.) Not breaking user code silently in undetectable ways. >> >> This is of course the utmost priority. It guides much of the AMP, >> including the 'backwards' direction of most of the dependencies. e.g. The >> reality is a large number of folks wrote (*>) = (>>) in their code, so e.g. >> if we defined (>>) = (*>), we'd get a large chunk of existing production >> code that just turns into infinite loops. We can always do more later as we >> find it is safe, but "first do no harm." >> >> 2.) Not introducing rampant performance regressions. >> >> David Feuer has been spending untold hours on this, and his work there is >> a large part of the source of endless waves of proposals he's been putting >> forth. >> >> Considering `liftM2` as 'redundant' from `liftA2` can be dangerous on >> this front. >> >> The decision of if we can alias liftM3 to liftA3 needs to be at least >> *partially* guided by the question of whether the latter is a viable >> replacement in practice. I'm not prepared to come down on one side of that >> debate without more profiling data. >> >> Adding liftA4, liftA5 runs afoul of neither of these caveats. Aliasing >> liftMn to liftAn is something that *potentially* runs afoul of the >> latter, and is something that we don't have to do in a frantic rush. The >> world won't end if we play it safe and don't get to it in time for 7.10. >> >> -Edward >> >> On Sat, Nov 8, 2014 at 7:42 AM, Andreas Abel wrote: >> >>> I am a bit alert about this discussion because it seems that we have >>> quite different ideas about how the AMP implementation should affect the >>> base libraries. >>> >>> 1. Where can we see and discuss the proposed changes? >>> >>> Not on https://www.haskell.org/haskellwiki/Functor- >>> Applicative-Monad_Proposal >>> >>> Not on https://ghc.haskell.org/trac/ghc/ticket/9586 >>> >>> 2. Imho, the reasonable thing is to >>> >>> rewrite all of F/A/M base functions such that they use the minimal >>> F/A/M constraints. >>> >>> This of course includes >>> >>> liftM :: (Functor m) => (a -> b) -> m a -> m b >>> liftM2 :: (Applicative m) => (a -> b -> c) -> m a -> m b -> m c >>> >>> and sequence and friends even if the M postfix can then "only explained >>> historically" (HT). >>> >>> One can say "M" stands for "effectful", but the minimal type class to >>> realize the effect is chosen from F/A/M. >>> >>> If we burn bridges, we should do it properly. >>> >>> Cheers, >>> Andreas >>> >>> >>> On 07.11.2014 20:35, Edward Kmett wrote: >>> >>>> I don't want them for rewriting liftM4 and liftM5, I want them in their >>>> own right. >>>> >>>> It doesn't do anyone any good to just have random asymmetries in the API >>>> like that. >>>> >>>> It just means a user goes to reach for a tool, doesn't find it and >>>> flails around. >>>> >>>> -Edward >>>> >>>> On Fri, Nov 7, 2014 at 1:37 PM, John Lato >>> > wrote: >>>> >>>> I still don't think it's worth adding liftA4 and liftA5 just so that >>>> liftM4+ can be rewritten. >>>> >>>> Very weakly -0.1 >>>> >>>> On Fri Nov 07 2014 at 10:24:27 AM David Feuer < >>>> david.feuer at gmail.com >>>> > wrote: >>>> >>>> Another point: using `liftA` or `liftM`, specialized to the >>>> relevant type, may reduce code size in some cases. With f <$> a >>>> <*> b <*> c and such, you have to hope that you either get some >>>> benefit from the inlining or that CSE is able to save you from >>>> the duplication. >>>> >>>> On Fri, Nov 7, 2014 at 7:47 AM, Jacques Carette >>>> > wrote: >>>> >>>> On 2014-11-07 5:30 AM, Henning Thielemann wrote: >>>> >>>> >>>> On Fri, 7 Nov 2014, Andreas Abel wrote: >>>> >>>> I hope the same happens for sequence, mapM and the >>>> like! >>>> >>>> sequence :: (Applicative m) => [m a] -> m [a] >>>> sequence = foldr (\ x xs -> (:) <$> x <*> xs) >>>> (pure []) >>>> >>>> >>>> Actually, this is an example, where liftA2 shows its >>>> advantage: >>>> >>>> sequence = foldr (liftA2 (:)) (pure []) >>>> >>>> This looks much clearer to me than decoding the mixture >>>> of infix and uninfixed infix operators. It simply says, >>>> that 'sequence' is like 'id = foldr (:) []' but with >>>> everything lifted to an applicative functor. >>>> >>>> >>>> I agree. I have lots of code which looks really clean >>>> because I can use liftA2 (and even liftA3) in exactly the >>>> way above. Having to eta expand everything obscures the >>>> real meat of what is going on. >>>> >>>> Jacques >>>> >>>> _________________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://www.haskell.org/__mailman/listinfo/libraries >>>> >>>> >>>> >>>> _________________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://www.haskell.org/__mailman/listinfo/libraries >>>> >>>> >>>> >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://www.haskell.org/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://www2.tcs.ifi.lmu.de/~abel/ >>> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Thu Jul 14 19:09:26 2016 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 14 Jul 2016 15:09:26 -0400 Subject: Proposal: Add Foldable helper to Control.DeepSeq In-Reply-To: References: Message-ID: The monoid may be more efficient if the Foldable is constructed to take advantage of internal sharing. -Edward On Thu, Jul 14, 2016 at 11:52 AM, David Feuer wrote: > I guess these are equivalent to the simpler expressions > > rnfLTR = foldl' (const rnf) () > rnfRTL = foldr' (\x _ -> rnf x) () > > On Jul 13, 2016 11:16 PM, "David Feuer" wrote: > >> As I describe in https://github.com/haskell/deepseq/issues/17 it is >> possible to implement an NFData instance for any Foldable type, and we >> can offer a function to help do that: >> >> data Unit = Unit >> >> instance Monoid Unit where >> mempty = Unit >> Unit `mappend` Unit = Unit -- strict in both arguments, unlike () >> >> rnfFoldable :: (Foldable f, NFData a) => f a -> () >> rnfFoldable xs = foldMap (\x -> rnf x `seq` Unit) xs `seq` () >> >> This could be used like so: >> >> instance NFData a => NFData (F a) where >> rnf = rnfFoldable >> >> This version forces from left to right. It would be possible to offer >> another version that forces from right to left: >> >> data Unit2 = Unit2 >> >> instance Monoid Unit2 where >> mempty = Unit2 >> x `mappend` Unit2 = x `seq` Unit2 >> >> rnfFoldableRTL :: (Foldable f, NFData a) => f a -> () >> rnfFoldableRTL xs = foldMap (\x -> rnf x `seq` Unit2) xs `seq` () >> > > _______________________________________________ > 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 spam at scientician.net Thu Jul 14 20:24:50 2016 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 14 Jul 2016 22:24:50 +0200 Subject: Discussion: add more idiomatic versions of catchJust and/or handleJust In-Reply-To: References: Message-ID: On 07/14/2016 08:06 PM, Oleg Grenrus wrote: > Maybe pointing out the obvious, but when used with lens, catchJust approach is handy: > > — | here catchJust is from `exceptions` though > catching :: MonadCatch m => Getting (First a) SomeException a -> m r -> (a -> m r) -> m r > catching l = catchJust (preview l) > > http://hackage.haskell.org/package/lens-4.14/docs/src/Control.Exception.Lens.html#catching lens is not a very appealing to have as a dependency if one is oneself writing a library for others to consume. (Because of the huge set of dependencies.) From david.feuer at gmail.com Thu Jul 14 20:52:32 2016 From: david.feuer at gmail.com (David Feuer) Date: Thu, 14 Jul 2016 16:52:32 -0400 Subject: Discussion: add more idiomatic versions of catchJust and/or handleJust In-Reply-To: <5787D188.2080703@ifi.lmu.de> References: <5787D188.2080703@ifi.lmu.de> Message-ID: Handle is no good because it clashes with file handles. How about Reaction? On Jul 14, 2016 1:53 PM, "Andreas Abel" wrote: > Maybe rather > > data Handle a = Rethrow | Handle (IO a) > > !? > On 14.07.2016 19:12, David Feuer wrote: > >> That makes sense, I guess. Something like >> >> data Handle a = Rethrow | Catch (IO a) >> >> I suppose? My names are awful though. >> >> >> On Jul 14, 2016 12:56 PM, "Oliver Charles" > > wrote: >> >> >> >> On Tue, 12 Jul 2016, 1:23 a.m. David Feuer, > > wrote: >> >> The catchJust and handleJust functions seem a bit weird and >> unidiomatic. >> >> catchJust >> :: Exception e >> => (e -> Maybe b) -- ^ Predicate to select >> exceptions >> -> IO a -- ^ Computation to run >> -> (b -> IO a) -- ^ Handler >> -> IO a >> catchJust p a handler = catch a handler' >> where handler' e = case p e of >> Nothing -> throwIO e >> Just b -> handler b >> >> This takes two functions and then puts them together. I would >> think the more natural API would be >> >> catchMaybe :: Exception e => IO a -> (e -> Maybe (IO a)) -> IO a >> catchMaybe m handler = catch m handler' where >> handler' e = fromMaybe (throwIO e) (handler e) >> >> A point don't feel super strongly about, but feel I should raise, is >> that Nothing seems to be somewhat confusing. catchJust >> (\FileNotFound -> Nothing) seems to suggest that if FileNotFound >> occurs then nothing will happen, that is - the exception is ignored. >> However, that is not the case, rather than Nothing happening >> something certainly happens - an exception is (re)thrown! >> >> Whether or not this confusion is likely to happen in practice I >> don't know, but it suggests a type isomorphic to Maybe is a better >> fit. >> >> Ollie >> >> >> >> _______________________________________________ >> 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://www2.tcs.ifi.lmu.de/~abel/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at ocharles.org.uk Thu Jul 14 21:42:24 2016 From: ollie at ocharles.org.uk (Oliver Charles) Date: Thu, 14 Jul 2016 21:42:24 +0000 Subject: Discussion: add more idiomatic versions of catchJust and/or handleJust In-Reply-To: References: <5787D188.2080703@ifi.lmu.de> Message-ID: data ExceptionHandler a = Rethrow | HandleException (IO a) would be my offering of paint. On Thu, Jul 14, 2016 at 9:52 PM David Feuer wrote: > Handle is no good because it clashes with file handles. How about Reaction? > > On Jul 14, 2016 1:53 PM, "Andreas Abel" wrote: > >> Maybe rather >> >> data Handle a = Rethrow | Handle (IO a) >> >> !? >> On 14.07.2016 19:12, David Feuer wrote: >> >>> That makes sense, I guess. Something like >>> >>> data Handle a = Rethrow | Catch (IO a) >>> >>> I suppose? My names are awful though. >>> >>> >>> On Jul 14, 2016 12:56 PM, "Oliver Charles" >> > wrote: >>> >>> >>> >>> On Tue, 12 Jul 2016, 1:23 a.m. David Feuer, >> > wrote: >>> >>> The catchJust and handleJust functions seem a bit weird and >>> unidiomatic. >>> >>> catchJust >>> :: Exception e >>> => (e -> Maybe b) -- ^ Predicate to select >>> exceptions >>> -> IO a -- ^ Computation to run >>> -> (b -> IO a) -- ^ Handler >>> -> IO a >>> catchJust p a handler = catch a handler' >>> where handler' e = case p e of >>> Nothing -> throwIO e >>> Just b -> handler b >>> >>> This takes two functions and then puts them together. I would >>> think the more natural API would be >>> >>> catchMaybe :: Exception e => IO a -> (e -> Maybe (IO a)) -> IO a >>> catchMaybe m handler = catch m handler' where >>> handler' e = fromMaybe (throwIO e) (handler e) >>> >>> A point don't feel super strongly about, but feel I should raise, is >>> that Nothing seems to be somewhat confusing. catchJust >>> (\FileNotFound -> Nothing) seems to suggest that if FileNotFound >>> occurs then nothing will happen, that is - the exception is ignored. >>> However, that is not the case, rather than Nothing happening >>> something certainly happens - an exception is (re)thrown! >>> >>> Whether or not this confusion is likely to happen in practice I >>> don't know, but it suggests a type isomorphic to Maybe is a better >>> fit. >>> >>> Ollie >>> >>> >>> >>> _______________________________________________ >>> 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://www2.tcs.ifi.lmu.de/~abel/ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Jul 14 22:20:08 2016 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 14 Jul 2016 18:20:08 -0400 Subject: Discussion: add more idiomatic versions of catchJust and/or handleJust In-Reply-To: References: <5787D188.2080703@ifi.lmu.de> Message-ID: At this point maybe it'd be better to write out these ideas as a library and implement a bunch of example codes for different approaches. Changing the interfaces for exception handling code is subtle stuff! On Jul 14, 2016 5:42 PM, "Oliver Charles" wrote: > data ExceptionHandler a = Rethrow | HandleException (IO a) > > would be my offering of paint. > > On Thu, Jul 14, 2016 at 9:52 PM David Feuer wrote: > >> Handle is no good because it clashes with file handles. How about >> Reaction? >> >> On Jul 14, 2016 1:53 PM, "Andreas Abel" wrote: >> >>> Maybe rather >>> >>> data Handle a = Rethrow | Handle (IO a) >>> >>> !? >>> On 14.07.2016 19:12, David Feuer wrote: >>> >>>> That makes sense, I guess. Something like >>>> >>>> data Handle a = Rethrow | Catch (IO a) >>>> >>>> I suppose? My names are awful though. >>>> >>>> >>>> On Jul 14, 2016 12:56 PM, "Oliver Charles" >>> > wrote: >>>> >>>> >>>> >>>> On Tue, 12 Jul 2016, 1:23 a.m. David Feuer, >>> > wrote: >>>> >>>> The catchJust and handleJust functions seem a bit weird and >>>> unidiomatic. >>>> >>>> catchJust >>>> :: Exception e >>>> => (e -> Maybe b) -- ^ Predicate to select >>>> exceptions >>>> -> IO a -- ^ Computation to run >>>> -> (b -> IO a) -- ^ Handler >>>> -> IO a >>>> catchJust p a handler = catch a handler' >>>> where handler' e = case p e of >>>> Nothing -> throwIO e >>>> Just b -> handler b >>>> >>>> This takes two functions and then puts them together. I would >>>> think the more natural API would be >>>> >>>> catchMaybe :: Exception e => IO a -> (e -> Maybe (IO a)) -> IO a >>>> catchMaybe m handler = catch m handler' where >>>> handler' e = fromMaybe (throwIO e) (handler e) >>>> >>>> A point don't feel super strongly about, but feel I should raise, is >>>> that Nothing seems to be somewhat confusing. catchJust >>>> (\FileNotFound -> Nothing) seems to suggest that if FileNotFound >>>> occurs then nothing will happen, that is - the exception is ignored. >>>> However, that is not the case, rather than Nothing happening >>>> something certainly happens - an exception is (re)thrown! >>>> >>>> Whether or not this confusion is likely to happen in practice I >>>> don't know, but it suggests a type isomorphic to Maybe is a better >>>> fit. >>>> >>>> Ollie >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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://www2.tcs.ifi.lmu.de/~abel/ >>> >> > _______________________________________________ > 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 davidleothomas at gmail.com Fri Jul 15 04:55:16 2016 From: davidleothomas at gmail.com (David Thomas) Date: Thu, 14 Jul 2016 21:55:16 -0700 Subject: Discussion: add more idiomatic versions of catchJust and/or handleJust In-Reply-To: References: <5787D188.2080703@ifi.lmu.de> Message-ID: I kinda like "ExceptionDisposition" for the type, no particular ideas on the constructors. Offered only in the spirit of tossing out ideas - feel free to ignore me if it's not helpful :) On Thu, Jul 14, 2016 at 3:20 PM, Carter Schonwald wrote: > At this point maybe it'd be better to write out these ideas as a library and > implement a bunch of example codes for different approaches. Changing the > interfaces for exception handling code is subtle stuff! > > > On Jul 14, 2016 5:42 PM, "Oliver Charles" wrote: >> >> data ExceptionHandler a = Rethrow | HandleException (IO a) >> >> would be my offering of paint. >> >> On Thu, Jul 14, 2016 at 9:52 PM David Feuer wrote: >>> >>> Handle is no good because it clashes with file handles. How about >>> Reaction? >>> >>> >>> On Jul 14, 2016 1:53 PM, "Andreas Abel" wrote: >>>> >>>> Maybe rather >>>> >>>> data Handle a = Rethrow | Handle (IO a) >>>> >>>> !? >>>> On 14.07.2016 19:12, David Feuer wrote: >>>>> >>>>> That makes sense, I guess. Something like >>>>> >>>>> data Handle a = Rethrow | Catch (IO a) >>>>> >>>>> I suppose? My names are awful though. >>>>> >>>>> >>>>> On Jul 14, 2016 12:56 PM, "Oliver Charles" >>>> > wrote: >>>>> >>>>> >>>>> >>>>> On Tue, 12 Jul 2016, 1:23 a.m. David Feuer, >>>> > wrote: >>>>> >>>>> The catchJust and handleJust functions seem a bit weird and >>>>> unidiomatic. >>>>> >>>>> catchJust >>>>> :: Exception e >>>>> => (e -> Maybe b) -- ^ Predicate to select >>>>> exceptions >>>>> -> IO a -- ^ Computation to run >>>>> -> (b -> IO a) -- ^ Handler >>>>> -> IO a >>>>> catchJust p a handler = catch a handler' >>>>> where handler' e = case p e of >>>>> Nothing -> throwIO e >>>>> Just b -> handler b >>>>> >>>>> This takes two functions and then puts them together. I would >>>>> think the more natural API would be >>>>> >>>>> catchMaybe :: Exception e => IO a -> (e -> Maybe (IO a)) -> IO >>>>> a >>>>> catchMaybe m handler = catch m handler' where >>>>> handler' e = fromMaybe (throwIO e) (handler e) >>>>> >>>>> A point don't feel super strongly about, but feel I should raise, >>>>> is >>>>> that Nothing seems to be somewhat confusing. catchJust >>>>> (\FileNotFound -> Nothing) seems to suggest that if FileNotFound >>>>> occurs then nothing will happen, that is - the exception is >>>>> ignored. >>>>> However, that is not the case, rather than Nothing happening >>>>> something certainly happens - an exception is (re)thrown! >>>>> >>>>> Whether or not this confusion is likely to happen in practice I >>>>> don't know, but it suggests a type isomorphic to Maybe is a better >>>>> fit. >>>>> >>>>> Ollie >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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://www2.tcs.ifi.lmu.de/~abel/ >> >> >> _______________________________________________ >> 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 carter.schonwald at gmail.com Fri Jul 15 13:23:16 2016 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 15 Jul 2016 09:23:16 -0400 Subject: Discussion: add more idiomatic versions of catchJust and/or handleJust In-Reply-To: References: <5787D188.2080703@ifi.lmu.de> Message-ID: Again, at this juncture it sounds like effort would be better spent first writing out an alternative userland lib to understand these design ideas / articulate their impact better On Friday, July 15, 2016, David Thomas wrote: > I kinda like "ExceptionDisposition" for the type, no particular ideas > on the constructors. Offered only in the spirit of tossing out ideas > - feel free to ignore me if it's not helpful :) > > On Thu, Jul 14, 2016 at 3:20 PM, Carter Schonwald > > wrote: > > At this point maybe it'd be better to write out these ideas as a library > and > > implement a bunch of example codes for different approaches. Changing > the > > interfaces for exception handling code is subtle stuff! > > > > > > On Jul 14, 2016 5:42 PM, "Oliver Charles" > wrote: > >> > >> data ExceptionHandler a = Rethrow | HandleException (IO a) > >> > >> would be my offering of paint. > >> > >> On Thu, Jul 14, 2016 at 9:52 PM David Feuer > wrote: > >>> > >>> Handle is no good because it clashes with file handles. How about > >>> Reaction? > >>> > >>> > >>> On Jul 14, 2016 1:53 PM, "Andreas Abel" > wrote: > >>>> > >>>> Maybe rather > >>>> > >>>> data Handle a = Rethrow | Handle (IO a) > >>>> > >>>> !? > >>>> On 14.07.2016 19:12, David Feuer wrote: > >>>>> > >>>>> That makes sense, I guess. Something like > >>>>> > >>>>> data Handle a = Rethrow | Catch (IO a) > >>>>> > >>>>> I suppose? My names are awful though. > >>>>> > >>>>> > >>>>> On Jul 14, 2016 12:56 PM, "Oliver Charles" > >>>>> >> wrote: > >>>>> > >>>>> > >>>>> > >>>>> On Tue, 12 Jul 2016, 1:23 a.m. David Feuer, < > david.feuer at gmail.com > >>>>> >> wrote: > >>>>> > >>>>> The catchJust and handleJust functions seem a bit weird and > >>>>> unidiomatic. > >>>>> > >>>>> catchJust > >>>>> :: Exception e > >>>>> => (e -> Maybe b) -- ^ Predicate to select > >>>>> exceptions > >>>>> -> IO a -- ^ Computation to run > >>>>> -> (b -> IO a) -- ^ Handler > >>>>> -> IO a > >>>>> catchJust p a handler = catch a handler' > >>>>> where handler' e = case p e of > >>>>> Nothing -> throwIO e > >>>>> Just b -> handler b > >>>>> > >>>>> This takes two functions and then puts them together. I would > >>>>> think the more natural API would be > >>>>> > >>>>> catchMaybe :: Exception e => IO a -> (e -> Maybe (IO a)) -> > IO > >>>>> a > >>>>> catchMaybe m handler = catch m handler' where > >>>>> handler' e = fromMaybe (throwIO e) (handler e) > >>>>> > >>>>> A point don't feel super strongly about, but feel I should raise, > >>>>> is > >>>>> that Nothing seems to be somewhat confusing. catchJust > >>>>> (\FileNotFound -> Nothing) seems to suggest that if FileNotFound > >>>>> occurs then nothing will happen, that is - the exception is > >>>>> ignored. > >>>>> However, that is not the case, rather than Nothing happening > >>>>> something certainly happens - an exception is (re)thrown! > >>>>> > >>>>> Whether or not this confusion is likely to happen in practice I > >>>>> don't know, but it suggests a type isomorphic to Maybe is a > better > >>>>> fit. > >>>>> > >>>>> Ollie > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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://www2.tcs.ifi.lmu.de/~abel/ > >> > >> > >> _______________________________________________ > >> 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 Fri Jul 15 13:44:14 2016 From: david.feuer at gmail.com (David Feuer) Date: Fri, 15 Jul 2016 09:44:14 -0400 Subject: Discussion: add more idiomatic versions of catchJust and/or handleJust In-Reply-To: References: <5787D188.2080703@ifi.lmu.de> Message-ID: You are very welcome to do so if you don't think further discussion will be useful. Those who feel otherwise may continue to discuss it. On Jul 15, 2016 9:23 AM, "Carter Schonwald" wrote: > Again, at this juncture it sounds like effort would be better spent first > writing out an alternative userland lib to understand these design ideas / > articulate their impact better > > On Friday, July 15, 2016, David Thomas wrote: > >> I kinda like "ExceptionDisposition" for the type, no particular ideas >> on the constructors. Offered only in the spirit of tossing out ideas >> - feel free to ignore me if it's not helpful :) >> >> On Thu, Jul 14, 2016 at 3:20 PM, Carter Schonwald >> wrote: >> > At this point maybe it'd be better to write out these ideas as a >> library and >> > implement a bunch of example codes for different approaches. Changing >> the >> > interfaces for exception handling code is subtle stuff! >> > >> > >> > On Jul 14, 2016 5:42 PM, "Oliver Charles" >> wrote: >> >> >> >> data ExceptionHandler a = Rethrow | HandleException (IO a) >> >> >> >> would be my offering of paint. >> >> >> >> On Thu, Jul 14, 2016 at 9:52 PM David Feuer >> wrote: >> >>> >> >>> Handle is no good because it clashes with file handles. How about >> >>> Reaction? >> >>> >> >>> >> >>> On Jul 14, 2016 1:53 PM, "Andreas Abel" >> wrote: >> >>>> >> >>>> Maybe rather >> >>>> >> >>>> data Handle a = Rethrow | Handle (IO a) >> >>>> >> >>>> !? >> >>>> On 14.07.2016 19:12, David Feuer wrote: >> >>>>> >> >>>>> That makes sense, I guess. Something like >> >>>>> >> >>>>> data Handle a = Rethrow | Catch (IO a) >> >>>>> >> >>>>> I suppose? My names are awful though. >> >>>>> >> >>>>> >> >>>>> On Jul 14, 2016 12:56 PM, "Oliver Charles" > >>>>> > wrote: >> >>>>> >> >>>>> >> >>>>> >> >>>>> On Tue, 12 Jul 2016, 1:23 a.m. David Feuer, < >> david.feuer at gmail.com >> >>>>> > wrote: >> >>>>> >> >>>>> The catchJust and handleJust functions seem a bit weird and >> >>>>> unidiomatic. >> >>>>> >> >>>>> catchJust >> >>>>> :: Exception e >> >>>>> => (e -> Maybe b) -- ^ Predicate to select >> >>>>> exceptions >> >>>>> -> IO a -- ^ Computation to run >> >>>>> -> (b -> IO a) -- ^ Handler >> >>>>> -> IO a >> >>>>> catchJust p a handler = catch a handler' >> >>>>> where handler' e = case p e of >> >>>>> Nothing -> throwIO e >> >>>>> Just b -> handler b >> >>>>> >> >>>>> This takes two functions and then puts them together. I >> would >> >>>>> think the more natural API would be >> >>>>> >> >>>>> catchMaybe :: Exception e => IO a -> (e -> Maybe (IO a)) -> >> IO >> >>>>> a >> >>>>> catchMaybe m handler = catch m handler' where >> >>>>> handler' e = fromMaybe (throwIO e) (handler e) >> >>>>> >> >>>>> A point don't feel super strongly about, but feel I should >> raise, >> >>>>> is >> >>>>> that Nothing seems to be somewhat confusing. catchJust >> >>>>> (\FileNotFound -> Nothing) seems to suggest that if FileNotFound >> >>>>> occurs then nothing will happen, that is - the exception is >> >>>>> ignored. >> >>>>> However, that is not the case, rather than Nothing happening >> >>>>> something certainly happens - an exception is (re)thrown! >> >>>>> >> >>>>> Whether or not this confusion is likely to happen in practice I >> >>>>> don't know, but it suggests a type isomorphic to Maybe is a >> better >> >>>>> fit. >> >>>>> >> >>>>> Ollie >> >>>>> >> >>>>> >> >>>>> >> >>>>> _______________________________________________ >> >>>>> 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://www2.tcs.ifi.lmu.de/~abel/ >> >> >> >> >> >> _______________________________________________ >> >> 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 carter.schonwald at gmail.com Fri Jul 15 14:46:58 2016 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 15 Jul 2016 10:46:58 -0400 Subject: Discussion: add more idiomatic versions of catchJust and/or handleJust In-Reply-To: References: <5787D188.2080703@ifi.lmu.de> Message-ID: Respectfully I disagree. You are pushing a breaking change to functionality in the base exception Api without a) demonstrating the Api is better b) understanding the impact on preexisting code that would needlessly break c) without doing a prototype outside of base to demonstrate that this alternative is better both in terms of the underlying library complexity and how the resulting application complexity changes. I am voicing an opinion other readers on the libraries list have on this matter but are too polite or wise to air this feedback publicly. The onus is on the proposer to demonstrate validity. Cheers -Carter On Friday, July 15, 2016, David Feuer wrote: > You are very welcome to do so if you don't think further discussion will > be useful. Those who feel otherwise may continue to discuss it. > > On Jul 15, 2016 9:23 AM, "Carter Schonwald" > wrote: > >> Again, at this juncture it sounds like effort would be better spent first >> writing out an alternative userland lib to understand these design ideas / >> articulate their impact better >> >> On Friday, July 15, 2016, David Thomas > > wrote: >> >>> I kinda like "ExceptionDisposition" for the type, no particular ideas >>> on the constructors. Offered only in the spirit of tossing out ideas >>> - feel free to ignore me if it's not helpful :) >>> >>> On Thu, Jul 14, 2016 at 3:20 PM, Carter Schonwald >>> wrote: >>> > At this point maybe it'd be better to write out these ideas as a >>> library and >>> > implement a bunch of example codes for different approaches. Changing >>> the >>> > interfaces for exception handling code is subtle stuff! >>> > >>> > >>> > On Jul 14, 2016 5:42 PM, "Oliver Charles" >>> wrote: >>> >> >>> >> data ExceptionHandler a = Rethrow | HandleException (IO a) >>> >> >>> >> would be my offering of paint. >>> >> >>> >> On Thu, Jul 14, 2016 at 9:52 PM David Feuer >>> wrote: >>> >>> >>> >>> Handle is no good because it clashes with file handles. How about >>> >>> Reaction? >>> >>> >>> >>> >>> >>> On Jul 14, 2016 1:53 PM, "Andreas Abel" >>> wrote: >>> >>>> >>> >>>> Maybe rather >>> >>>> >>> >>>> data Handle a = Rethrow | Handle (IO a) >>> >>>> >>> >>>> !? >>> >>>> On 14.07.2016 19:12, David Feuer wrote: >>> >>>>> >>> >>>>> That makes sense, I guess. Something like >>> >>>>> >>> >>>>> data Handle a = Rethrow | Catch (IO a) >>> >>>>> >>> >>>>> I suppose? My names are awful though. >>> >>>>> >>> >>>>> >>> >>>>> On Jul 14, 2016 12:56 PM, "Oliver Charles" >> >>>>> > wrote: >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> On Tue, 12 Jul 2016, 1:23 a.m. David Feuer, < >>> david.feuer at gmail.com >>> >>>>> > wrote: >>> >>>>> >>> >>>>> The catchJust and handleJust functions seem a bit weird and >>> >>>>> unidiomatic. >>> >>>>> >>> >>>>> catchJust >>> >>>>> :: Exception e >>> >>>>> => (e -> Maybe b) -- ^ Predicate to select >>> >>>>> exceptions >>> >>>>> -> IO a -- ^ Computation to run >>> >>>>> -> (b -> IO a) -- ^ Handler >>> >>>>> -> IO a >>> >>>>> catchJust p a handler = catch a handler' >>> >>>>> where handler' e = case p e of >>> >>>>> Nothing -> throwIO e >>> >>>>> Just b -> handler b >>> >>>>> >>> >>>>> This takes two functions and then puts them together. I >>> would >>> >>>>> think the more natural API would be >>> >>>>> >>> >>>>> catchMaybe :: Exception e => IO a -> (e -> Maybe (IO a)) >>> -> IO >>> >>>>> a >>> >>>>> catchMaybe m handler = catch m handler' where >>> >>>>> handler' e = fromMaybe (throwIO e) (handler e) >>> >>>>> >>> >>>>> A point don't feel super strongly about, but feel I should >>> raise, >>> >>>>> is >>> >>>>> that Nothing seems to be somewhat confusing. catchJust >>> >>>>> (\FileNotFound -> Nothing) seems to suggest that if >>> FileNotFound >>> >>>>> occurs then nothing will happen, that is - the exception is >>> >>>>> ignored. >>> >>>>> However, that is not the case, rather than Nothing happening >>> >>>>> something certainly happens - an exception is (re)thrown! >>> >>>>> >>> >>>>> Whether or not this confusion is likely to happen in practice I >>> >>>>> don't know, but it suggests a type isomorphic to Maybe is a >>> better >>> >>>>> fit. >>> >>>>> >>> >>>>> Ollie >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> 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://www2.tcs.ifi.lmu.de/~abel/ >>> >> >>> >> >>> >> _______________________________________________ >>> >> 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 davean at xkcd.com Fri Jul 15 15:57:01 2016 From: davean at xkcd.com (davean) Date: Fri, 15 Jul 2016 11:57:01 -0400 Subject: Discussion: add more idiomatic versions of catchJust and/or handleJust In-Reply-To: References: <5787D188.2080703@ifi.lmu.de> Message-ID: I'm -1 on changing the currently named functions. Which you only imply doing to my reading but I think Carter takes you as proposing given your use of said names in proposing the signatures. Overall I'm +0. I see code the alternative signature could be nicer for, but I'm not sure I'd use it or why this is starting as a library discussion instead of on hackage. I just would prefer not to lose the existing signature's availability. On Jul 15, 2016 10:46 AM, "Carter Schonwald" wrote: > Respectfully I disagree. > > You are pushing a breaking change to functionality in the base exception > Api without > a) demonstrating the Api is better > b) understanding the impact on preexisting code that would needlessly > break > c) without doing a prototype outside of base to demonstrate that this > alternative is better both in terms of the underlying library complexity > and how the resulting application complexity changes. > > I am voicing an opinion other readers on the libraries list have on this > matter but are too polite or wise to air this feedback publicly. > > The onus is on the proposer to demonstrate validity. > > Cheers > -Carter > > On Friday, July 15, 2016, David Feuer wrote: > >> You are very welcome to do so if you don't think further discussion will >> be useful. Those who feel otherwise may continue to discuss it. >> >> On Jul 15, 2016 9:23 AM, "Carter Schonwald" >> wrote: >> >>> Again, at this juncture it sounds like effort would be better spent >>> first writing out an alternative userland lib to understand these design >>> ideas / articulate their impact better >>> >>> On Friday, July 15, 2016, David Thomas wrote: >>> >>>> I kinda like "ExceptionDisposition" for the type, no particular ideas >>>> on the constructors. Offered only in the spirit of tossing out ideas >>>> - feel free to ignore me if it's not helpful :) >>>> >>>> On Thu, Jul 14, 2016 at 3:20 PM, Carter Schonwald >>>> wrote: >>>> > At this point maybe it'd be better to write out these ideas as a >>>> library and >>>> > implement a bunch of example codes for different approaches. >>>> Changing the >>>> > interfaces for exception handling code is subtle stuff! >>>> > >>>> > >>>> > On Jul 14, 2016 5:42 PM, "Oliver Charles" >>>> wrote: >>>> >> >>>> >> data ExceptionHandler a = Rethrow | HandleException (IO a) >>>> >> >>>> >> would be my offering of paint. >>>> >> >>>> >> On Thu, Jul 14, 2016 at 9:52 PM David Feuer >>>> wrote: >>>> >>> >>>> >>> Handle is no good because it clashes with file handles. How about >>>> >>> Reaction? >>>> >>> >>>> >>> >>>> >>> On Jul 14, 2016 1:53 PM, "Andreas Abel" >>>> wrote: >>>> >>>> >>>> >>>> Maybe rather >>>> >>>> >>>> >>>> data Handle a = Rethrow | Handle (IO a) >>>> >>>> >>>> >>>> !? >>>> >>>> On 14.07.2016 19:12, David Feuer wrote: >>>> >>>>> >>>> >>>>> That makes sense, I guess. Something like >>>> >>>>> >>>> >>>>> data Handle a = Rethrow | Catch (IO a) >>>> >>>>> >>>> >>>>> I suppose? My names are awful though. >>>> >>>>> >>>> >>>>> >>>> >>>>> On Jul 14, 2016 12:56 PM, "Oliver Charles" >>> >>>>> > wrote: >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> On Tue, 12 Jul 2016, 1:23 a.m. David Feuer, < >>>> david.feuer at gmail.com >>>> >>>>> > wrote: >>>> >>>>> >>>> >>>>> The catchJust and handleJust functions seem a bit weird >>>> and >>>> >>>>> unidiomatic. >>>> >>>>> >>>> >>>>> catchJust >>>> >>>>> :: Exception e >>>> >>>>> => (e -> Maybe b) -- ^ Predicate to >>>> select >>>> >>>>> exceptions >>>> >>>>> -> IO a -- ^ Computation to run >>>> >>>>> -> (b -> IO a) -- ^ Handler >>>> >>>>> -> IO a >>>> >>>>> catchJust p a handler = catch a handler' >>>> >>>>> where handler' e = case p e of >>>> >>>>> Nothing -> throwIO e >>>> >>>>> Just b -> handler b >>>> >>>>> >>>> >>>>> This takes two functions and then puts them together. I >>>> would >>>> >>>>> think the more natural API would be >>>> >>>>> >>>> >>>>> catchMaybe :: Exception e => IO a -> (e -> Maybe (IO a)) >>>> -> IO >>>> >>>>> a >>>> >>>>> catchMaybe m handler = catch m handler' where >>>> >>>>> handler' e = fromMaybe (throwIO e) (handler e) >>>> >>>>> >>>> >>>>> A point don't feel super strongly about, but feel I should >>>> raise, >>>> >>>>> is >>>> >>>>> that Nothing seems to be somewhat confusing. catchJust >>>> >>>>> (\FileNotFound -> Nothing) seems to suggest that if >>>> FileNotFound >>>> >>>>> occurs then nothing will happen, that is - the exception is >>>> >>>>> ignored. >>>> >>>>> However, that is not the case, rather than Nothing happening >>>> >>>>> something certainly happens - an exception is (re)thrown! >>>> >>>>> >>>> >>>>> Whether or not this confusion is likely to happen in practice >>>> I >>>> >>>>> don't know, but it suggests a type isomorphic to Maybe is a >>>> better >>>> >>>>> fit. >>>> >>>>> >>>> >>>>> Ollie >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> _______________________________________________ >>>> >>>>> 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://www2.tcs.ifi.lmu.de/~abel/ >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> 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 david.feuer at gmail.com Fri Jul 15 17:50:39 2016 From: david.feuer at gmail.com (David Feuer) Date: Fri, 15 Jul 2016 13:50:39 -0400 Subject: Discussion: add more idiomatic versions of catchJust and/or handleJust In-Reply-To: References: <5787D188.2080703@ifi.lmu.de> Message-ID: No one is proposing removing or changing the current functions. Maybe you should re-read the thread. Unnamed people who don't voice their own opinions don't count for much. On Jul 15, 2016 10:46 AM, "Carter Schonwald" wrote: > Respectfully I disagree. > > You are pushing a breaking change to functionality in the base exception > Api without > a) demonstrating the Api is better > b) understanding the impact on preexisting code that would needlessly > break > c) without doing a prototype outside of base to demonstrate that this > alternative is better both in terms of the underlying library complexity > and how the resulting application complexity changes. > > I am voicing an opinion other readers on the libraries list have on this > matter but are too polite or wise to air this feedback publicly. > > The onus is on the proposer to demonstrate validity. > > Cheers > -Carter > > On Friday, July 15, 2016, David Feuer wrote: > >> You are very welcome to do so if you don't think further discussion will >> be useful. Those who feel otherwise may continue to discuss it. >> >> On Jul 15, 2016 9:23 AM, "Carter Schonwald" >> wrote: >> >>> Again, at this juncture it sounds like effort would be better spent >>> first writing out an alternative userland lib to understand these design >>> ideas / articulate their impact better >>> >>> On Friday, July 15, 2016, David Thomas wrote: >>> >>>> I kinda like "ExceptionDisposition" for the type, no particular ideas >>>> on the constructors. Offered only in the spirit of tossing out ideas >>>> - feel free to ignore me if it's not helpful :) >>>> >>>> On Thu, Jul 14, 2016 at 3:20 PM, Carter Schonwald >>>> wrote: >>>> > At this point maybe it'd be better to write out these ideas as a >>>> library and >>>> > implement a bunch of example codes for different approaches. >>>> Changing the >>>> > interfaces for exception handling code is subtle stuff! >>>> > >>>> > >>>> > On Jul 14, 2016 5:42 PM, "Oliver Charles" >>>> wrote: >>>> >> >>>> >> data ExceptionHandler a = Rethrow | HandleException (IO a) >>>> >> >>>> >> would be my offering of paint. >>>> >> >>>> >> On Thu, Jul 14, 2016 at 9:52 PM David Feuer >>>> wrote: >>>> >>> >>>> >>> Handle is no good because it clashes with file handles. How about >>>> >>> Reaction? >>>> >>> >>>> >>> >>>> >>> On Jul 14, 2016 1:53 PM, "Andreas Abel" >>>> wrote: >>>> >>>> >>>> >>>> Maybe rather >>>> >>>> >>>> >>>> data Handle a = Rethrow | Handle (IO a) >>>> >>>> >>>> >>>> !? >>>> >>>> On 14.07.2016 19:12, David Feuer wrote: >>>> >>>>> >>>> >>>>> That makes sense, I guess. Something like >>>> >>>>> >>>> >>>>> data Handle a = Rethrow | Catch (IO a) >>>> >>>>> >>>> >>>>> I suppose? My names are awful though. >>>> >>>>> >>>> >>>>> >>>> >>>>> On Jul 14, 2016 12:56 PM, "Oliver Charles" >>> >>>>> > wrote: >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> On Tue, 12 Jul 2016, 1:23 a.m. David Feuer, < >>>> david.feuer at gmail.com >>>> >>>>> > wrote: >>>> >>>>> >>>> >>>>> The catchJust and handleJust functions seem a bit weird >>>> and >>>> >>>>> unidiomatic. >>>> >>>>> >>>> >>>>> catchJust >>>> >>>>> :: Exception e >>>> >>>>> => (e -> Maybe b) -- ^ Predicate to >>>> select >>>> >>>>> exceptions >>>> >>>>> -> IO a -- ^ Computation to run >>>> >>>>> -> (b -> IO a) -- ^ Handler >>>> >>>>> -> IO a >>>> >>>>> catchJust p a handler = catch a handler' >>>> >>>>> where handler' e = case p e of >>>> >>>>> Nothing -> throwIO e >>>> >>>>> Just b -> handler b >>>> >>>>> >>>> >>>>> This takes two functions and then puts them together. I >>>> would >>>> >>>>> think the more natural API would be >>>> >>>>> >>>> >>>>> catchMaybe :: Exception e => IO a -> (e -> Maybe (IO a)) >>>> -> IO >>>> >>>>> a >>>> >>>>> catchMaybe m handler = catch m handler' where >>>> >>>>> handler' e = fromMaybe (throwIO e) (handler e) >>>> >>>>> >>>> >>>>> A point don't feel super strongly about, but feel I should >>>> raise, >>>> >>>>> is >>>> >>>>> that Nothing seems to be somewhat confusing. catchJust >>>> >>>>> (\FileNotFound -> Nothing) seems to suggest that if >>>> FileNotFound >>>> >>>>> occurs then nothing will happen, that is - the exception is >>>> >>>>> ignored. >>>> >>>>> However, that is not the case, rather than Nothing happening >>>> >>>>> something certainly happens - an exception is (re)thrown! >>>> >>>>> >>>> >>>>> Whether or not this confusion is likely to happen in practice >>>> I >>>> >>>>> don't know, but it suggests a type isomorphic to Maybe is a >>>> better >>>> >>>>> fit. >>>> >>>>> >>>> >>>>> Ollie >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> _______________________________________________ >>>> >>>>> 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://www2.tcs.ifi.lmu.de/~abel/ >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> 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 david.feuer at gmail.com Mon Jul 18 18:10:04 2016 From: david.feuer at gmail.com (David Feuer) Date: Mon, 18 Jul 2016 14:10:04 -0400 Subject: Proposal: Add Foldable helper to Control.DeepSeq In-Reply-To: References: Message-ID: I've put up a pull request at https://github.com/haskell/deepseq/pull/18 adding rnfFoldableLTR and rnfFoldableRTL, and documenting when they can (and when they cannot) produce good NFData instances. The implementations are monoid based, but use slightly different monoid definitions than originally proposed so as to produce extremely clean Core for GHC >= 7.8 even without specialization. Edward: similar functions could also be written for Bifoldable. I'd be happy to send a PR to bifunctors if you'd like. On Jul 14, 2016 3:09 PM, "Edward Kmett" wrote: > The monoid may be more efficient if the Foldable is constructed to take > advantage of internal sharing. > > -Edward > > On Thu, Jul 14, 2016 at 11:52 AM, David Feuer > wrote: > >> I guess these are equivalent to the simpler expressions >> >> rnfLTR = foldl' (const rnf) () >> rnfRTL = foldr' (\x _ -> rnf x) () >> >> On Jul 13, 2016 11:16 PM, "David Feuer" wrote: >> >>> As I describe in https://github.com/haskell/deepseq/issues/17 it is >>> possible to implement an NFData instance for any Foldable type, and we >>> can offer a function to help do that: >>> >>> data Unit = Unit >>> >>> instance Monoid Unit where >>> mempty = Unit >>> Unit `mappend` Unit = Unit -- strict in both arguments, unlike () >>> >>> rnfFoldable :: (Foldable f, NFData a) => f a -> () >>> rnfFoldable xs = foldMap (\x -> rnf x `seq` Unit) xs `seq` () >>> >>> This could be used like so: >>> >>> instance NFData a => NFData (F a) where >>> rnf = rnfFoldable >>> >>> This version forces from left to right. It would be possible to offer >>> another version that forces from right to left: >>> >>> data Unit2 = Unit2 >>> >>> instance Monoid Unit2 where >>> mempty = Unit2 >>> x `mappend` Unit2 = x `seq` Unit2 >>> >>> rnfFoldableRTL :: (Foldable f, NFData a) => f a -> () >>> rnfFoldableRTL xs = foldMap (\x -> rnf x `seq` Unit2) xs `seq` () >>> >> >> _______________________________________________ >> 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 Thu Jul 21 23:18:59 2016 From: david.feuer at gmail.com (David Feuer) Date: Thu, 21 Jul 2016 19:18:59 -0400 Subject: Proposal: Add gcoerceWith to Data.Type.Coercion Message-ID: In Data.Type.Equality, we have both castWith :: (a :~: b) -> a -> b and gcastWith :: (a :~: b) -> (a ~ b => r) -> r But in Data.Type.Coercion we only have coerceWith :: Coercion a b -> a -> b It seems to me that for the sake of consistency, we should add gcoerceWith :: Coercion a b -> (Coercible a b => r) -> r gcoerceWith Coercion a = a David Feuer From ekmett at gmail.com Thu Jul 21 23:27:17 2016 From: ekmett at gmail.com (Edward Kmett) Date: Fri, 22 Jul 2016 01:27:17 +0200 Subject: Proposal: Add gcoerceWith to Data.Type.Coercion In-Reply-To: References: Message-ID: No objection here. +1 -Edward On Fri, Jul 22, 2016 at 1:18 AM, David Feuer wrote: > In Data.Type.Equality, we have both > > castWith :: (a :~: b) -> a -> b > > and > > gcastWith :: (a :~: b) -> (a ~ b => r) -> r > > > But in Data.Type.Coercion we only have > > > coerceWith :: Coercion a b -> a -> b > > > It seems to me that for the sake of consistency, we should add > > > gcoerceWith :: Coercion a b -> (Coercible a b => r) -> r > gcoerceWith Coercion a = a > > David Feuer > _______________________________________________ > 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 ollie at ocharles.org.uk Fri Jul 22 08:58:12 2016 From: ollie at ocharles.org.uk (Oliver Charles) Date: Fri, 22 Jul 2016 08:58:12 +0000 Subject: Proposal: Add gcoerceWith to Data.Type.Coercion In-Reply-To: References: Message-ID: I have wanted this exact function before. +1 On Fri, 22 Jul 2016, 12:27 a.m. Edward Kmett, wrote: > No objection here. +1 > > -Edward > > On Fri, Jul 22, 2016 at 1:18 AM, David Feuer > wrote: > >> In Data.Type.Equality, we have both >> >> castWith :: (a :~: b) -> a -> b >> >> and >> >> gcastWith :: (a :~: b) -> (a ~ b => r) -> r >> >> >> But in Data.Type.Coercion we only have >> >> >> coerceWith :: Coercion a b -> a -> b >> >> >> It seems to me that for the sake of consistency, we should add >> >> >> gcoerceWith :: Coercion a b -> (Coercible a b => r) -> r >> gcoerceWith Coercion a = a >> >> David Feuer >> _______________________________________________ >> 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 rae at cs.brynmawr.edu Fri Jul 22 13:43:49 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Fri, 22 Jul 2016 09:43:49 -0400 Subject: Proposal: Add gcoerceWith to Data.Type.Coercion In-Reply-To: References: Message-ID: +1 I'm not sure why that was left out. > On Jul 22, 2016, at 4:58 AM, Oliver Charles wrote: > > I have wanted this exact function before. +1 > > > On Fri, 22 Jul 2016, 12:27 a.m. Edward Kmett, > wrote: > No objection here. +1 > > -Edward > > On Fri, Jul 22, 2016 at 1:18 AM, David Feuer > wrote: > In Data.Type.Equality, we have both > > castWith :: (a :~: b) -> a -> b > > and > > gcastWith :: (a :~: b) -> (a ~ b => r) -> r > > > But in Data.Type.Coercion we only have > > > coerceWith :: Coercion a b -> a -> b > > > It seems to me that for the sake of consistency, we should add > > > gcoerceWith :: Coercion a b -> (Coercible a b => r) -> r > gcoerceWith Coercion a = a > > David Feuer > _______________________________________________ > 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 david.feuer at gmail.com Mon Jul 25 16:11:55 2016 From: david.feuer at gmail.com (David Feuer) Date: Mon, 25 Jul 2016 12:11:55 -0400 Subject: Proposal: Add `restriction` to Data.Map and Data.IntMap In-Reply-To: References: <20160714155446.GA11038@city.ac.uk> <20160714163603.GA28546@octa> Message-ID: I got distracted from this discussion for a bit. Based on input from the list, and Ross Paterson's remark about argument order, I'm currently thinking restrictKeys :: Ord k => Map k a -> Set k -> Map k a and withoutKeys :: Ord k => Map k a -> Set k -> Map k a Are there any major objections? On Thu, Jul 14, 2016 at 12:54 PM, Alexey Vagarenko wrote: > How about `keepKeys`? > > 2016-07-14 21:36 GMT+05:00 Daniel Trstenjak : >> >> On Thu, Jul 14, 2016 at 12:02:51PM -0400, David Feuer wrote: >> > If you name it, it will come! >> >> intersectKeys and differentiateKeys >> >> or >> >> intersectionWithSet and differenceWithSet >> >> or ;) >> >> intersectionOfKeys and differenceOfKeys >> >> >> Greetings, >> Daniel >> _______________________________________________ >> 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 ekmett at gmail.com Mon Jul 25 17:10:50 2016 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 25 Jul 2016 13:10:50 -0400 Subject: Proposal: Add `restriction` to Data.Map and Data.IntMap In-Reply-To: References: <20160714155446.GA11038@city.ac.uk> <20160714163603.GA28546@octa> Message-ID: Good enough for me. On Mon, Jul 25, 2016 at 12:11 PM, David Feuer wrote: > I got distracted from this discussion for a bit. Based on input from > the list, and Ross Paterson's remark about argument order, I'm > currently thinking > > restrictKeys :: Ord k => Map k a -> Set k -> Map k a > > and > > withoutKeys :: Ord k => Map k a -> Set k -> Map k a > > Are there any major objections? > > On Thu, Jul 14, 2016 at 12:54 PM, Alexey Vagarenko > wrote: > > How about `keepKeys`? > > > > 2016-07-14 21:36 GMT+05:00 Daniel Trstenjak >: > >> > >> On Thu, Jul 14, 2016 at 12:02:51PM -0400, David Feuer wrote: > >> > If you name it, it will come! > >> > >> intersectKeys and differentiateKeys > >> > >> or > >> > >> intersectionWithSet and differenceWithSet > >> > >> or ;) > >> > >> intersectionOfKeys and differenceOfKeys > >> > >> > >> Greetings, > >> Daniel > >> _______________________________________________ > >> 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 david.feuer at gmail.com Mon Jul 25 18:59:58 2016 From: david.feuer at gmail.com (David Feuer) Date: Mon, 25 Jul 2016 14:59:58 -0400 Subject: Proposal: Add `restriction` to Data.Map and Data.IntMap In-Reply-To: References: <20160714155446.GA11038@city.ac.uk> <20160714163603.GA28546@octa> Message-ID: A final question: Both `restrictKeys` and `withoutKeys` are special cases of `filterWithKey` (although they should be considerably more efficient than implementations using that function). Do we also want a `partition` special case, in which a map is partitioned into the keys that are in a set and the ones that are not? On Mon, Jul 25, 2016 at 1:10 PM, Edward Kmett wrote: > Good enough for me. > > On Mon, Jul 25, 2016 at 12:11 PM, David Feuer wrote: >> >> I got distracted from this discussion for a bit. Based on input from >> the list, and Ross Paterson's remark about argument order, I'm >> currently thinking >> >> restrictKeys :: Ord k => Map k a -> Set k -> Map k a >> >> and >> >> withoutKeys :: Ord k => Map k a -> Set k -> Map k a >> >> Are there any major objections? >> >> On Thu, Jul 14, 2016 at 12:54 PM, Alexey Vagarenko >> wrote: >> > How about `keepKeys`? >> > >> > 2016-07-14 21:36 GMT+05:00 Daniel Trstenjak >> > : >> >> >> >> On Thu, Jul 14, 2016 at 12:02:51PM -0400, David Feuer wrote: >> >> > If you name it, it will come! >> >> >> >> intersectKeys and differentiateKeys >> >> >> >> or >> >> >> >> intersectionWithSet and differenceWithSet >> >> >> >> or ;) >> >> >> >> intersectionOfKeys and differenceOfKeys >> >> >> >> >> >> Greetings, >> >> Daniel >> >> _______________________________________________ >> >> 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 abela at chalmers.se Mon Jul 25 19:34:58 2016 From: abela at chalmers.se (Andreas Abel) Date: Mon, 25 Jul 2016 21:34:58 +0200 Subject: Proposal: Add `restriction` to Data.Map and Data.IntMap In-Reply-To: References: <20160714155446.GA11038@city.ac.uk> <20160714163603.GA28546@octa> Message-ID: <5afcb01e-4d04-e364-25ab-9366ae162c35@chalmers.se> Seems like the partition function would subsume the others?! partitionByKeys :: Ord k => Set k -> Map k a -> (Map k a, Map k a) Would there be impressive speed gains for a native fst . partitionByKeys set ? On 25.07.2016 20:59, David Feuer wrote: > A final question: > > Both `restrictKeys` and `withoutKeys` are special cases of > `filterWithKey` (although they should be considerably more efficient > than implementations using that function). Do we also want a > `partition` special case, in which a map is partitioned into the keys > that are in a set and the ones that are not? > > On Mon, Jul 25, 2016 at 1:10 PM, Edward Kmett wrote: >> Good enough for me. >> >> On Mon, Jul 25, 2016 at 12:11 PM, David Feuer wrote: >>> >>> I got distracted from this discussion for a bit. Based on input from >>> the list, and Ross Paterson's remark about argument order, I'm >>> currently thinking >>> >>> restrictKeys :: Ord k => Map k a -> Set k -> Map k a >>> >>> and >>> >>> withoutKeys :: Ord k => Map k a -> Set k -> Map k a >>> >>> Are there any major objections? >>> >>> On Thu, Jul 14, 2016 at 12:54 PM, Alexey Vagarenko >>> wrote: >>>> How about `keepKeys`? >>>> >>>> 2016-07-14 21:36 GMT+05:00 Daniel Trstenjak >>>> : >>>>> >>>>> On Thu, Jul 14, 2016 at 12:02:51PM -0400, David Feuer wrote: >>>>>> If you name it, it will come! >>>>> >>>>> intersectKeys and differentiateKeys >>>>> >>>>> or >>>>> >>>>> intersectionWithSet and differenceWithSet >>>>> >>>>> or ;) >>>>> >>>>> intersectionOfKeys and differenceOfKeys >>>>> >>>>> >>>>> Greetings, >>>>> Daniel >>>>> _______________________________________________ >>>>> 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 >> >> > _______________________________________________ > 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://www2.tcs.ifi.lmu.de/~abel/ From david.feuer at gmail.com Mon Jul 25 19:45:56 2016 From: david.feuer at gmail.com (David Feuer) Date: Mon, 25 Jul 2016 15:45:56 -0400 Subject: Proposal: Add `restriction` to Data.Map and Data.IntMap In-Reply-To: <5afcb01e-4d04-e364-25ab-9366ae162c35@chalmers.se> References: <20160714155446.GA11038@city.ac.uk> <20160714163603.GA28546@octa> <5afcb01e-4d04-e364-25ab-9366ae162c35@chalmers.se> Message-ID: I'm not sure yet, but I suspect it might be possible to implement partitionByKeySet more efficiently than the naive way. But to do so, it will have to construct both pieces eagerly, meaning that using only part of its result will waste time and allocation. On Mon, Jul 25, 2016 at 3:34 PM, Andreas Abel wrote: > Seems like the partition function would subsume the others?! > > partitionByKeys :: Ord k => Set k -> Map k a -> (Map k a, Map k a) > > Would there be impressive speed gains for a native > > fst . partitionByKeys set > > ? > > > On 25.07.2016 20:59, David Feuer wrote: >> >> A final question: >> >> Both `restrictKeys` and `withoutKeys` are special cases of >> `filterWithKey` (although they should be considerably more efficient >> than implementations using that function). Do we also want a >> `partition` special case, in which a map is partitioned into the keys >> that are in a set and the ones that are not? >> >> On Mon, Jul 25, 2016 at 1:10 PM, Edward Kmett wrote: >>> >>> Good enough for me. >>> >>> On Mon, Jul 25, 2016 at 12:11 PM, David Feuer >>> wrote: >>>> >>>> >>>> I got distracted from this discussion for a bit. Based on input from >>>> the list, and Ross Paterson's remark about argument order, I'm >>>> currently thinking >>>> >>>> restrictKeys :: Ord k => Map k a -> Set k -> Map k a >>>> >>>> and >>>> >>>> withoutKeys :: Ord k => Map k a -> Set k -> Map k a >>>> >>>> Are there any major objections? >>>> >>>> On Thu, Jul 14, 2016 at 12:54 PM, Alexey Vagarenko >>>> wrote: >>>>> >>>>> How about `keepKeys`? >>>>> >>>>> 2016-07-14 21:36 GMT+05:00 Daniel Trstenjak >>>>> : >>>>>> >>>>>> >>>>>> On Thu, Jul 14, 2016 at 12:02:51PM -0400, David Feuer wrote: >>>>>>> >>>>>>> If you name it, it will come! >>>>>> >>>>>> >>>>>> intersectKeys and differentiateKeys >>>>>> >>>>>> or >>>>>> >>>>>> intersectionWithSet and differenceWithSet >>>>>> >>>>>> or ;) >>>>>> >>>>>> intersectionOfKeys and differenceOfKeys >>>>>> >>>>>> >>>>>> Greetings, >>>>>> Daniel >>>>>> _______________________________________________ >>>>>> 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 >>> >>> >>> >> _______________________________________________ >> 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://www2.tcs.ifi.lmu.de/~abel/ > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From mail at joachim-breitner.de Mon Jul 25 22:05:14 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 26 Jul 2016 00:05:14 +0200 Subject: Proposal: Add `restriction` to Data.Map and Data.IntMap In-Reply-To: References: <20160714155446.GA11038@city.ac.uk> <20160714163603.GA28546@octa> Message-ID: <1469484314.11330.3.camel@joachim-breitner.de> Hi, Am Montag, den 25.07.2016, 14:59 -0400 schrieb David Feuer: > Both `restrictKeys` and `withoutKeys` are special cases of > `filterWithKey` (although they should be considerably more efficient > than implementations using that function). I’m risking to derailing this discussion, but how viable would it be to *not* add a new exported name for this, but recommend (e.g. in the docs) to use filter (`S.elem` set) map and then rely on rewrite rules to get the desired performance effect (by rewriting this expression to an non-exported restrictKeys)? I guess the answer is: Not viable enough, because rewrite rules are not applied reliably enough, and because you cannot easily have the effect of a partial "map `restrictKeys`". But nevertheless it is an interesting idea to imagine a programming language where APIs can be minimal, modular and composable without performance penalties. 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: 819 bytes Desc: This is a digitally signed message part URL: From ekmett at gmail.com Mon Jul 25 23:49:40 2016 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 25 Jul 2016 19:49:40 -0400 Subject: Proposal: Add `restriction` to Data.Map and Data.IntMap In-Reply-To: <1469484314.11330.3.camel@joachim-breitner.de> References: <20160714155446.GA11038@city.ac.uk> <20160714163603.GA28546@octa> <1469484314.11330.3.camel@joachim-breitner.de> Message-ID: Given the fragility of rewrite rules (and the fact that they don't happen at all at the default optimization level) that seems too delicate of a solution to endorse. That doesn't prevent us from adding the rewrite rules to try to help existing code that already uses filter (`S.member` set), in addition to these combinators, though. That idiom is already rather common given the lack of an alternative to date and improving its performance wouldn't hurt. -Edward On Mon, Jul 25, 2016 at 6:05 PM, Joachim Breitner wrote: > Hi, > > Am Montag, den 25.07.2016, 14:59 -0400 schrieb David Feuer: > > Both `restrictKeys` and `withoutKeys` are special cases of > > `filterWithKey` (although they should be considerably more efficient > > than implementations using that function). > > I’m risking to derailing this discussion, but how viable would it be to > *not* add a new exported name for this, but recommend (e.g. in the > docs) to use > > filter (`S.elem` set) map > > and then rely on rewrite rules to get the desired performance effect > (by rewriting this expression to an non-exported restrictKeys)? > > I guess the answer is: Not viable enough, because rewrite rules are not > applied reliably enough, and because you cannot easily have the effect > of a partial "map `restrictKeys`". But nevertheless it is an > interesting idea to imagine a programming language where APIs can be > minimal, modular and composable without performance penalties. > > 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 > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: