- Libraries - Haskell.org

Re: Proposal: flipped fmap in base (again)
by Ryan Scott 10 Mar '17

10 Mar '17

+1 from me as well on including (<&>) in base. I wouldn't object to adding ffor either, if folks with find that useful. Ryan S.

1 0

Proposal: flipped fmap in base (again)
by Siddhanathan Shanmugam 10 Mar '17

10 Mar '17

This was proposed about 7 years ago, and rejected at the time: https://ghc.haskell.org/trac/ghc/ticket/3962 Is it okay if I revive this argument now? I think it would be useful to have the lens operator <&> in base, which is defined as: (<&>) :: Functor f => f a -> (a -> b) -> f b as <&> f = f <$> as This is analogous to a lifted version of (&) that already present in Data.Function Cheers, Sid

9 17

Alternative.some and NonEmpty
by Vladislav Zavialov 08 Mar '17

08 Mar '17

Since 'Data.List.NonEmpty' is now in 'base', it makes sense to change the type of 'some' from some :: Alternative f => f a -> f [a] to some :: Alternative f => f a -> f (NonEmpty a) as it's guaranteed to return a non-empty list. Currently, both users and implementors of 'Alternative' instances are at a disadvantage. The users have to use the unsafe NonEmpty.fromList function to take advantage of the fact that the result of 'some' is indeed non-empty. The implementors have more space for error - it's possible to accidentally return an empty list. I volunteer to implement. Does everyone agree it's a good idea?

9 15

Re: Deprecate Foldable for Either
by dominic＠steinitz.org 06 Mar '17

06 Mar '17

Is anyone arguing that this is acceptable? > On 5 Mar 2017, at 10:32, libraries-request(a)haskell.org wrote: > > sum ([1,2,3], 1) == 1 On another note, the change that allowed this has brought discord to a previously harmonious community. I for one regret this. Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

2 1

Proposal: modify `Read` instances for `Float` and `Double`
by Iavor Diatchki 05 Mar '17

05 Mar '17

Hello, I am working on a small GHC extension to support floating point literals in hexadecimal notation (https://github.com/ghc-proposals/ghc-proposals/pull/37) which is similar to what's available in other languages. To support this change, I would like to propose that we modify the `Read` instances for `Float` and `Double` to parse literals in the new notation. This may affect existing programs---although it doesn't seem very likely. Here is an example: current behavior: reads "0x10p10" = [(16.0,"p10")] new behavior: reads "0x10p10" = [(16384,"")] What do people think? -Iavor

6 7

Re: [Haskell-cafe] Inlinable (>>>)
by Joe Hillenbrand 03 Mar '17

03 Mar '17

CCing Libraries On Thu, Mar 2, 2017 at 7:18 AM, David Sorokin <david.sorokin(a)gmail.com> wrote: > Hi Cafe, > > I offer to define the functions of the Control.Category module inlinable: > > -- | Right-to-left composition > (<<<) :: Category cat => cat b c -> cat a b -> cat a c > {-# INLINABLE (<<<) #-} > (<<<) = (.) > > -- | Left-to-right composition > (>>>) :: Category cat => cat a b -> cat b c -> cat a c > {-# INLINABLE (>>>) #-} > f >>> g = g . f > > Perhaps all functions from this module should be marked by this pragma as possible. > > I suppose that the current definition without the pragma is the cause why the execution slows down in my applications, when using monad parameters in the constraints. I noticed it yet two or three years ago, while playing with the monad transformers, but decided to write now. > > Best regards, > David Sorokin > > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post.

1 0

Proposal: make throwIO and throw strict
by David Feuer 27 Feb '17

27 Feb '17

It's possible for code to throw an exception that itself throws an imprecise exception. Such an exception is a bit tricky to catch. For example: import Control.Exception strange = throwIO (undefined :: SomeException) `catch` \ex -> case () of _ | Just _ <- (fromException ex :: Maybe IOError) -> print "IOError" | otherwise -> print "Something else" You might think that this would catch the exception and print "Something else", but in fact it does not. If others think this is as surprising as I do, then I think we should make throwIO and throw strict, so an exception will never itself be bottom. Using throwIO' !e = throwIO e in the code above instead of throwIO allows the exception to be caught. A more conservative approach might be to just force result of toException before calling raise#, but this only works when users use an explicit type signature to fix the expression type, rather than an exception constructor. David

2 1

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