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