July 2016 - Libraries

Proposal: merge either into transformers
by Roman Cheplyaka 03 Jan '17

03 Jan '17

I propose to add the sole module of the 'either' package[1], Control.Monad.Trans.Either, to the transformers package. It provides EitherT, a very basic and fundamental data type. The difference between EitherT and ErrorT is that the latter has an Error constraint, which is used to imlement 'fail'. Note that 'either' depends on the 'semigroupoids' and 'semigroup' packages to provide appropriate instances. The proposal is not to add those instances to 'transformers' to avoid additional dependencies. The instances can then be left in the 'either' package or moved to the 'semigroupoids' and 'semigroup' packages respectively. ('semigroupoids' already depends on 'transformers', while 'semigroups' does not). Compared to the 'either' package, Show, Read, Eq and Ord instances will be dropped to keep the code Haskell2010 (those instances require FlexibleInstances, FlexibleContexts, and UndecidableInstances). The patch is attached. [*] [*] against transformers-0.3.0.0, because the darcs version is not buildable (Control/Monad/Signatures.hs is not in the repository). Roman

22 72

Proposal: Add `restriction` to Data.Map and Data.IntMap
by David Feuer 25 Aug '16

25 Aug '16

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

15 27

Proposal: Add gcoerceWith to Data.Type.Coercion
by David Feuer 22 Jul '16

22 Jul '16

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

4 3

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