- Libraries - Haskell.org

Whither the AFPP?
by Boespflug, Mathieu 27 Feb '17

27 Feb '17

Hi all, a few folks got together to propose this nearly 2 years ago: https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath Has anything become of this proposal? Might it be helpful to have a similar process as ghc-proposals for changes in base and the boot libraries that do not otherwise affect the compiler or the language, so as to track the status of these things more consistently? Best, -- Mathieu Boespflug Founder at http://tweag.io.

5 5

Proposal: Add readMaybe (and possibly readEither) to Prelude, make Haddocks for read more cautionary
by Simon Jakobi 25 Feb '17

25 Feb '17

read [1] is an easy way to introduce runtime exceptions into programs, but its documentation doesn't sufficiently warn of this danger. read's safe alternatives, Text.Read.readMaybe [2] and Text.Read.readEither [3], are relatively unknown and too hard to find. To guide users (particularly newcomers) away from read and towards readMaybe and readEither, I propose to 1. Add readMaybe to the Prelude 2. Add readEither to the Prelude 3. Change the documentation for read to point out the partiality and to recommend the above alternatives: The haddocks for read currently read: > The read function reads input from a string, which must be completely consumed by the input process. I propose to add a paragraph roughly like this: > Note: read will throw an error if the parse fails. If there's any uncertainty w.r.t. the shape of the input, readMaybe or readEither should be used instead. Name clashes: A cursory code search on Github for readMaybe [4] reveals many existing definitions, mostly with the same type (Read a => String -> Maybe a) and definition. The same search for readEither [5] shows mostly GHC forks. Design issues: I am somewhat doubtful about the benefit of readEither over readMaybe: While readEither does give additional info on the kind of parse failures, that information is encoded in a String error message, from which it must be parsed if it is needed in the program. As the different parts of the proposal can be implemented independently of each other, please vote separately on each part of the proposal. Discussion period: 4 weeks. Cheers, Simon [1] http://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude.html#v:read [2] http://hackage.haskell.org/package/base-4.9.0.0/docs/Text-Read.html#v:readM… [3] http://hackage.haskell.org/package/base-4.9.0.0/docs/Text-Read.html#v:readE… [4] https://github.com/search?l=Haskell&q=readMaybe&type=Code [5] https://github.com/search?l=Haskell&q=readEither&type=Code

23 49

Proposal: Add splitL and splitR to container’s Map APIs
by Joachim Breitner 20 Feb '17

20 Feb '17

Hi, I regularly find myself in the need of splitting a map into two maps. For that we currently have these two functions: split :: Ord k => k -> Map k a -> (Map k a, Map k a) splitLookup :: Ord k => k -> Map k a -> (Map k a, Maybe a, Map k a) Usually, split is useless to me because information (the element right on the border) gets lost. splitLookup preserves the information, but often I want the element at the border to simply be in one of the two output maps. So I would like to see splitL :: Ord k => k -> Map k a -> (Map k a, Map k a) splitR :: Ord k => k -> Map k a -> (Map k a, Map k a) with these properties uncurry union (splitL k m) == m uncurry union (splitR k m) == m all (<= k) (keys (fst (splitL k m)) all (> k) (keys (snd (splitL k m)) all (< k) (keys (fst (splitR k m)) all (>= k) (keys (snd (splitR k m)) These new functions should be added to Data.Map, Data.IntMap (in both variatans each) and, for consistency, Data.Set. Alternative names (in correspondence with Data.Set.lookup{LT,LE,GT,TE}) would be splitLE (instead of splitL) and splitLT (instead of splitR). Corresponding issue: https://github.com/haskell/containers/issues/387 Discussion period: 2 weeks (until Feb 14). Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 4

What top-level names are “allocated”?
by Wolfgang Jeltsch 17 Feb '17

17 Feb '17

Hi! When uploading a new version of grapefruit-frp yesterday, I got the following warning from cabal-install: > Exposed modules use unallocated top-level names: FRP This made me wonder which top-level names are actually “allocated”. I tried to find this out from the Cabal sources, but the GitHub search functionality revealed no occurrences of the word “unallocated”. Regarding my concrete case, I think it would be good to change “FRP” to “Reactive”, which is what Reactive Banana is using, for example. However, is “Reactive” an “allocated” top-level name? All the best, Wolfgang

5 5

Proposal: Add a Void1 :: * -> * type to base
by Michael Walker 15 Feb '17

15 Feb '17

Hi, Recently I found myself in need of a type like Void, but taking a type parameter, so I wrote up a fairly simple implementation inspired by Data.Void: {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE EmptyCase #-} {-# LANGUAGE StandaloneDeriving #-} data Void1 a deriving Generic deriving instance Data a => Data (Void1 a) instance Ix (Void1 a) where range _ = [] index _ = absurd1 inRange _ = absurd1 rangeSize _ = 0 instance Typeable a => Exception (Void1 a) instance Eq (Void1 a) where _ == _ = True instance Ord (Void1 a) where compare _ _ = EQ instance Read (Void1 a) where readsPrec _ _ = [] instance Semigroup (Void1 a) where a <> _ = a instance Show (Void1 a) where show = absurd1 instance Functor Void1 where fmap _ = absurd1 instance Foldable Void1 where foldMap _ = absurd1 instance Traversable Void1 where traverse _ = absurd1 absurd1 :: Void1 a -> b absurd1 v = case v of {} (If we step outside the realm of base, this type is also a Contravariant and a Comonad) I left this sitting alone in a Utils module until last night when I saw someone ask in #haskell if there was "a Void1 type defined in some central place". So, in case this is of more general interest, I propose that a module Data.Functor.Void be added to base. Another colour to paint this bikeshed would be "VoidF", rather than "Void1". Also, this could be added to Data.Void rather than be a new module, but I think it's more sensible to include in the Data.Functor hierarchy, perhaps with a re-export from Data.Void. Discussion period: 2 weeks (ending Wed, 1st March) -- Michael Walker (http://www.barrucadu.co.uk)

3 2

Discussion: Implementation of fromList for Data.Set and Data.Map
by David Feuer 12 Feb '17

12 Feb '17

Currently, the implementations of fromList for Data.Set and Data.Map try to take advantage of inputs with some prefix in strictly increasing order. It uses the fast (O (n)) fromDistinctAscList algorithm for the strictly ascending prefix, and then falls back on the slower (O (n log n)) naive algorithm for the rest. For Data.Set, this works roughly like the implementation sketched at the bottom of this message. This whole thing strikes me as a bit odd: changing just the first element of the input list can have a substantial impact on the overall performance. In my opinion, there are two reasonable ways to implement this function: 1. Don't bother to try to take advantage of preexisting ordering. This is the simplest option, and will probably be fastest for lists with little preexisting order. 2. Try to take advantage of sorted ascending and descending "runs". A simple version would be to break up the input list into ascending and descending segments (merging duplicates on the fly), use fromDistinctAscList or fromDistinctDescList to convert each segment, and combine the segments using set unions. This option will be slower for totally unsorted lists, but should degrade much more gradually than the current algorithm as disorder is added. Wren suggests that there may be other variations on the same theme that we could consider. Should we A. Switch to 1 (and offer 2 by another name) B. Switch to 2 (and offer 1 by another name?) C. Leave fromList alone and offer 2 by another name Note that option 1 can be implemented quite easily outside the library using insert and foldl'; option 2 is not something users should be expected to write themselves. If we add names, what should those be? Thanks, David Feuer Current implementation sketch: fromList :: Ord a => [a] -> Set a fromList xs = foldl' (flip insert) sortedSet unsortedList where sortedSet = fromDistinctAscList sortedList (sortedList, unsortedList) = spanStrictlyAscending xs spanStrictlyAscending [] = ([], []) spanStrictlyAscending (x : xs) = x : go x xs where go prev (n : ns) | prev < n = first (n :) $ go n ns go _ ns = ([], ns)

4 5

Proposal: Make minimumBy and maximumBy go through foldl1
by David Laing 09 Feb '17

09 Feb '17

Hi all, I'm proposing that the implementations of minimumBy and maximumBy be changed from using foldl1 to foldr1. I found this in a GHC trac ticket[0] labelled 'Newcomer' that has more details / discussion on that. The points that stand out to me are: - the Haskell report says that those methods should be implemented in terms of foldl1 (although as instance methods of Foldable there might be some wiggle room there) - it helps solves a space leak (which at first glance feels like it might be a more common problem than the options that foldl1 removes) - from the discussion on the ticket, it seemed to be an agreeable middle ground As a side note: there have been a few proposals in the past to switch these functions to use foldl', which seemed to have stalled. I don't know what the etiquette is around bringing up minor variations on old proposals again, so I apologise if I've breached some kind of protocol here. Although I guess I've already breached one protocol by pushing a patch to Phabricator for review without getting sign-off from the Core Libraries Committee, so at least I'm being even handed with my clumsiness :) Cheers, Dave [0] https://ghc.haskell.org/trac/ghc/ticket/10830

6 8

Announcing containers 0.5.8.2, 0.5.9.2, and 0.5.10.1
by David Feuer 07 Feb '17

07 Feb '17

I had not planned to make any additional releases before GHC 8.2, but bugs forced my hand. In particular, Tom Smalley discovered major bugs in Data.IntMap.restrictKeys and Data.IntMap.withoutKeys. A mistake I made adding those functions to the test suite prevented the problem from being discovered. This affects both 0.5.8.1 and 0.5.9.1, both of which are now deprecated. I believe both the functions and the test suite are now working as intended. In a less frightening bug fix, Ryan Scott fixed a discrepancy between the Show1 instance for Data.Tree and its Show instance. This affected version 0.5.9.1. I also fixed misdirected Haddock links in 0.5.9.1. Version 0.5.10.1 comes with one new feature: Data.Sequence has a MonadZip instance. Thanks also to Simon Jakobi for removing the meaningless stability annotations. David Feuer

1 0

minor broken link in binary submodule
by Takenobu Tani 06 Feb '17

06 Feb '17

Dear libraries, I'm reporting about minor broken link in source comment. There is a broken link in `libraries/binary/src/Data/Binary/Get.hs`. --- <http://www.haskell.org/ghc/docs/latest/html/users_guide/ pragmas.html#unpack-pragma> +-- <http://www.haskell.org/ghc/docs/latest/html/users_guide/ glasgow_exts.html#unpack-pragma> Regards, Takenobu

1 0

Selection Monad
by Jakub Daniel 02 Feb '17

02 Feb '17

Hello, I apologize in case this is not the right place to bring this question/proposal up. Some time ago I stumbled upon the Selection Monad [1] (also referred to as Search from the search package on hackage). Its relation to the Continuation Monad and the usefulness demonstrated in [1] made me wonder whether it would be nice to include Selection Monad in the core libraries along the Continuation Monad (in mtl and transformers) with all the business of selections attaining continuations. I can imagine the pattern to be too little recognised to justify such an addition, yet the theoretical connection to the Continuation Monad seems to be an interesting one and worth being addressed. Best, Jakub Daniel [1] Jules Hedges. *Monad transformers for backtracking search*. In *Proceedings of MSFP 2014. *https://arxiv.org/abs/1406.2058

3 3