- Libraries - Haskell.org

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

Proposal: add ReadPrec-based functions to Read1/Read2
by Ryan Scott 20 Jun '16

20 Jun '16

GHC 8.0 added the Data.Functor.Classes module [1] to base, and with it the Read1 and Read2 typeclasses. The current definition of Read1 is this: class Read1 f where liftReadsPrec :: (Int -> ReadS a) -> ReadS [a] -> Int -> ReadS (f a) liftReadList :: (Int -> ReadS a) -> ReadS [a] -> ReadS [f a] There's a pretty big problem with this definition: it uses ReadS (a synonym for String -> [(a, String)]). This sort of parser is very slow (the docs even admit as such [2]), and moreover, the actual Read typeclass on which Read1 is based tries to avoid using it whenever possible. The Read typeclass has this definition currently: class Read a where readsPrec :: Int -> ReadS a readList :: ReadS [a] readPrec :: ReadPrec a readListPrec :: ReadPrec [a] Where ReadPrec is a much more efficient parser datatype. When deriving Read instances, GHC defines them in terms of readPrec, and gives the other methods default definitions that leverage readPrec. For the sake of consistency, I propose adding analogous methods to Read1 and Read2 that use the ReadPrec datatype. For example, here is how I would change Read1: class Read1 f where liftReadsPrec :: (Int -> ReadS a) -> ReadS [a] -> Int -> ReadS (f a) liftReadList :: (Int -> ReadS a) -> ReadS [a] -> ReadS [f a] liftReadPrec :: ReadPrec a -> ReadPrec [a] -> ReadPrec (f a) liftReadListPrec :: ReadPrec a -> ReadPrec [a] -> ReadPrec [f a] And similarly for Read2. Here is a full gist [3] with a sketch of what the new Read1/Read2 definitions would look like, including what the default definitions of the other methods would be. Ryan S. ----- [1] http://hackage.haskell.org/package/base-4.9.0.0/docs/Data-Functor-Classes.h… [2] http://hackage.haskell.org/package/base-4.9.0.0/docs/Text-ParserCombinators… [3] https://gist.github.com/RyanGlScott/7cdd11d6aa878e4229acf1a682beb1fc

4 3

bit sets in IntSet vs. Integer
by Henning Thielemann 19 Jun '16

19 Jun '16

In my set-cover package I make extensive use of bit vectors. I tested both IntSet and Integer for this purpose. In GHC-7.4.2 Integer was visibly faster than IntSet, but in GHC-7.8.4 and later, IntSet clearly wins over Integer. I guess this can be attributed to IntSet using BitMaps at the leaves since containers-0.5. However, on a 64-bit machine a BitMap is a Word64. I wondered whether we could get further speedup by using a vector type. E.g. AVX processors could perform bit manipulations on 256 bit words. Do the bit operations on Integer make use of vector instructions?

3 9

ANN: eccrypto, aka Hecc, hF2
by Marcel Fourné 15 Jun '16

15 Jun '16

Dear Haskell Community! It was a long~ish time ago I released hecc[1], which had an unfortunate but funny (to me) name, later together with hF2[2]. Since I have neither released hyperelliptic curve crypto support, nor my pairing based crypto, a generalising change in names would be in order. Today I am releasing eccrypto[3], which contains the code of both (to allow easier refactoring of new ideas) and something new: A pure Haskell, timing-attack resistant Ed25519[4] implementation! ...well, a very rough one at least. The code is not "done", gives wrong results, is _very_ slow, but it might serve as reading material as well as a primer what I plan to do in the future. I do not plan to add embedded C or assembler code, but plan to make the code comparatively fast to some common implementations as well as timing attack resistant (see: [5]), even if it will never be as fast as the best code used in contemporary benchmarks. Sadly, due to health issues, I am not able to work on said code and have not been for a time longer than I care to admit. All comments are welcome, but I will not be able to guarantee answers. ;) Best of wishes to a thriving community, Marcel Fourné [1]: https://hackage.haskell.org/package/hecc [2]: https://hackage.haskell.org/package/hF2 [3]: https://hackage.haskell.org/package/eccrypto [4]: https://ed25519.cr.yp.to/ [5]: https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118213.html

1 0

Proposal: add fromRight and fromLeft to Data.Either
by Anton Felix Lorenzen 12 Jun '16

12 Jun '16

When working with Either, I am often missing two simple functions: fromRight :: Either a b -> b fromLeft :: Either a b -> a It has been implemented a couple of times: http://hayoo.fh-wedel.de/?query=fromRight But I don't want to depend on yet another library for such a basic function. Could it be added? Anton

13 14