- Libraries - Haskell.org

Proposal: Add Foldable helper to Control.DeepSeq
by David Feuer 18 Jul '16

18 Jul '16

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` ()

3 4

Discussion: add more idiomatic versions of catchJust and/or handleJust
by David Feuer 15 Jul '16

15 Jul '16

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".

11 21

Proposal: add liftA4 and liftA5 to match liftM4 and liftM5
by David Feuer 14 Jul '16

14 Jul '16

Since Applicative is supposed to be important now, I figure we should get these in.

12 33

Proposal for containers: Add 'lookup' function to Data.Set
by Nicolas Godbout 14 Jul '16

14 Jul '16

WHAT It is proposed to add a ‘lookup' function on 'Set' in the "containers" package. Feedback during the next two weeks is welcome. The function > lookup :: Ord a => a -> Set a -> Maybe a is almost indentical to the 'member' function but, in addition, returns the value stored in the set. WHY The point of this proposal is to facilitate program-wide data sharing. The 'lookup' function gives access to a pointer to an object already stored in a Set and equal to a given argument. The 'lookup' function is a natural extension to the current 'lookupLT', 'lookupGT', 'lookupLE' and 'lookupGE' functions, with obvious semantics. 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. HOW The git pull request at https://github.com/haskell/containers/pull/291 contains the straight-forward implementation of the 'lookup’ function on 'Set', with test cases, as a patch against the current containers master branch. Salutations, Nicolas.

16 32

Proposal and discussion: Deprecate Data.Set.mapMonotonic and Data.Map.mapKeysMonotonic; add correctly named functions
by David Feuer 12 Jul '16

12 Jul '16

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

4 6

Re: Proposal for containers: Add 'lookup' function to Data.Set
by David Feuer 04 Jul '16

04 Jul '16

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" <nicolas.godbout(a)gmail.com> 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(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

2 2

Re: Interruptible exception wormholes kill modularity
by Yuras Shumovich 02 Jul '16

02 Jul '16

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.

1 0

Notification: adding adjust' to Data.Sequence (rage on!)
by David Feuer 29 Jun '16

29 Jun '16

This is not a proposal. I know that for reasons I don't know, the decision was made to move extra-strict functions for the other containers into separate .Strict modules. I greatly dislike the result of that decision (both from the API standpoint and especially from a maintenance standpoint), but I'm not arguing to change that. However, I am adding an extra-strict function to Data.Sequence, with the following non-negotiable semantics: adjust' f i xs = case xs !? i of Nothing -> xs Just x -> let !x' = f x in update i x' xs This will provide an efficient way to adjust a sequence element without risking thunk chains and memory leaks. I'm sure some people will be angry. I just wanted to make sure no one says I snuck this in behind their back.

1 0

User-friendly access to SmallArray# and SmallMutableArray#
by David Feuer 27 Jun '16

27 Jun '16

The only user-friendly wrappers I can find for SmallArray# and SmallMutableArray# are in Data.Discrimination.Internal.SmallArray in the discrimination package. What are the chances that we could get something like that in the array package, or possibly some other GHC boot package? I can't use discrimination in containers! David

3 4

How bad would it be for containers to depend on transformers?
by David Feuer 22 Jun '16

22 Jun '16

Currently, containers does not depend on transformers, so it has to duplicate its functionality or just do without. Since transformers is also a GHC boot package, I believe it should be feasible to make containers depend on it. To what extent would that reduce parallelizability of GHC builds or otherwise make people mad? David

2 1