December 2010 - Libraries

Proposal #3339: Add (+>) as a synonym for mappend
by Bryan O'Sullivan 08 Nov '11

08 Nov '11

Ticket: http://hackage.haskell.org/trac/ghc/ticket/3339 >From the ticket: This proposal was, I think, originally suggested by Jules Bean. The idea is to add two functions to the Data.Monoid module, (+>) and (<+), corresponding to different uses of mappend. These should not be methods of the Monoidtypeclass, but top-level functions. I hope (but slightly doubt) that the visual nature of the two operators might help to counter the thought that monoids are just for gluing things together. (+>) :: (Monoid a) => a -> a -> a a +> b = a `mappend` b (<+) :: (Monoid a) => a -> a -> a a <+ b = b `mappend` a infixl 4 +> infixl 4 <+ Proposed deadline: two weeks. If this looks reasonable, I'll attach darcs patches.

30 75

There are too many error handling conventions used in library code!
by dons＠cse.unsw.edu.au 13 Aug '11

13 Aug '11

This article on the 8 different error handling strategies various common Haskell libs use: http://www.randomhacks.net/articles/2007/03/10/haskell-8-ways-to-report-err… got me thinking: we need to standardise/recommend a small set of methods for library error handling. The lack of consistent error reporting between libs results in verbose code, as we're not able to use a single error handling technique when gluing together code from different libs (i.e. we can't just use Maybe or Either/ErrorT). (It's always nice when you *can* use, say, a Maybe monad to glue code from a number of sources, but eventually you reach code with a different error system, and the Maybe monad breaks down). So, some questions I think we can tackle: * can we identify error handling strategies from the list that should not be used anymore? (throwDyn?) * can we move some of the outlying libraries to a more consistent error framework? * do we need more support for gluing together our different error systems? (it should be easier to glue code using , say, Maybe/Either). * what role does MonadError play here, as a generic error handler? * can we make precise recommendations about which error strategies to use? -- Don

11 16

Proposal: add forkOnIO and friends to Control.Concurrent:
by Simon Marlow 30 Mar '11

30 Mar '11

Ticket: http://hackage.haskell.org/trac/ghc/ticket/4859 I think these functions are implementation-independent enough to add to the main `Control.Concurrent` API: {{{ {- | Like 'forkIO', but lets you specify on which CPU the thread is created. Unlike a `forkIO` thread, a thread created by `forkOnIO` will stay on the same CPU for its entire lifetime (`forkIO` threads can migrate between CPUs according to the scheduling policy). `forkOnIO` is useful for overriding the scheduling policy when you know in advance how best to distribute the threads. The `Int` argument specifies the CPU number; it is interpreted modulo the value returned by 'getNumCapabilities'. -} forkOnIO :: Int -> IO () -> IO ThreadId -- | Like 'forkIOWithUnmask', but the child thread is pinned to the -- given CPU, as with 'forkOnIO'. forkOnIOWithUnmask :: Int -> ((forall a . IO a -> IO a) -> IO ()) -> IO ThreadId {- | Returns the number of Haskell threads that can run truly simultaneously (on separate physical processors) at any given time. The CPU number passed to `forkOnIO` is interpreted modulo this value. An implementation in which Haskell threads are mapped directly to OS threads might return the number of physical processor cores in the machine, and 'forkOnIO' would be implemented using the OS's affinity facilities. An implementation that schedules Haskell threads onto a smaller number of OS threads (like GHC) would return the number of such OS threads that can be running simultaneously. GHC notes: this returns the number passed as the argument to the @+RTS -N@ flag. In current implementations, the value is fixed when the program starts and never changes, but it is possible that in the future the number of capabilities might vary at runtime. -} getNumCapabilities :: IO Int -- | returns @Just x@ if the given thread was created with either -- @forkOnIO x@ or @forkOnIOWithUnmask@, or @Nothing@ otherwise. threadIsPinned :: ThreadId -> IO (Maybe Int) }}} In base 4.3.0.0 (GHC 7.0.1) we currently have `forkOnIO` and `forkOnIOUnmasked`, available from `GHC.Conc`. I am about to add the other functions to `GHC.Conc`, and deprecate `forkOnIOUnmasked` (see http://hackage.haskell.org/trac/ghc/ticket/4457) This proposal is to export the above functions from`Control.Concurrent` too. A feature request for `threadIsPinned` was submitted as http://hackage.haskell.org/trac/ghc/ticket/4457. Naming is up for grabs: I'm not at all sure that "capabilities" is a good word here, but I can't think of any better ideas. "processors" or "CPUs" don't seem quite right. Discussion period: 4 weeks (until 19 Jan 2011) Cheers, Simon

12 18

System.IO.latin1 docs
by Wolfgang Jeltsch 30 Mar '11

30 Mar '11

Hello, on <http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/System-I…> it says: > An attempt to write a character greater than '\255' to a Handle using > the latin1 encoding will result in an error. However, according to my experience (with GHC 6.12.1 and base 4.2.0.0), latin1 just outputs a character '\cccc' as cccc `mod` 256. Should the docs be changed? Best wishes, Wolfgang

8 14

Proposal: Add chop function to Data.List
by Lennart Augustsson 08 Feb '11

08 Feb '11

I would like to propose the following function for inclusion in Data.List chop :: (a -> (b, [a]) -> [a] -> [b] chop _ [] = [] chop f as = b : chop f as' where (b, as') = f as It's commonly occuring recursion pattern. Typically chop is called with some function that will consume an initial prefix of the list and produce a value and the rest of the list. The function is clearly related to unfoldr, but I find it more convenient to use in a lot of cases. Some examples ------------- -- From Data.List group :: (Eq a) => [a] -> [[a]] group = chop (\ xs@(x:_) -> span (==x) xs) -- From Data.List words :: String -> [String] words = filter (not . null) . chop (span (not . isSpace) . dropWhile isSpace) -- From Data.List lines :: String -> [String] lines = chop ((id *** dropNL) . span (/= '\n')) where dropNL ('\n':s) = s; dropNL s = s -- From Data.List tails :: [a] -> [[a]] tails = (++ [[]]) . chop (\ xs@(_:xs') -> (xs, xs')) -- From Data.List map f = chop (\ (x:xs) -> (f x, xs)) -- Split a list into a list of list with length n. splitEveryN n = chop (splitAt n) -- Simple Haskell tokenizer tokenize = chop (head . lex) History ------- I first encountered this function around 1981 when I was talking to Sören Holmström about this recursion pattern and he said that he had also observed it and he called the function chopList. Ever since then I've used chopList a lot, but unfortunately I always have to make my own definition of this common function.

12 17

Proposal: Change to library proposal process
by Ian Lynagh 02 Feb '11

02 Feb '11

Hi all, The current proposal process requires that both a ticket is created and a mailing list post sent at the start of the proposal. The ticket creation means: * Redundant work is done: The same information is repeated in two places * Some replies end up on the list, while others end up as a ticket comment * Tickets for rejected or abandoned proposals tend to hang around, cluttering up the bug tracker I propose that proposals are instead started by sending a message to the list, and a ticket is only created when and if consensus for the change has been reached. This proposal is orthogonal to the proposal to give some libraries maintainers, so that they no longer use the process. The proposal process would change to: Start: Send a mail to libraries@, with subject beginning "Proposal:", containing details of the change and a proposed deadline (at least 2 weeks time). End: If consensus for the change has been reached, file a ticket in the GHC trac, including: * A link to the start of the thread in the archives * A summary of the discussion * Details of the change, ideally in the form of a patch Suggested deadline: 24 Jan 2011 Thanks Ian

20 36

Proposal: keep Data.Map.foldWithKey
by Christian Maeder 17 Jan '11

17 Jan '11

Hi, I've now created a proper library proposal to keep Data.Map.foldWithKey. Exchange arguments and make up your mind until Jan. 15th. http://hackage.haskell.org/trac/ghc/ticket/4842 Cheers Christian

8 45

Proposal: deepseq should not depend on containers
by Johan Tibell 10 Jan '11

10 Jan '11

Ticket: http://hackage.haskell.org/trac/ghc/ticket/4868 Copy of proposal: The deepseq package depends on the containers package. This forces all packages that want to depend on deepseq in order to provide a NFData instance for exported types, to also depend on containers. Proposal, have containers depend on deepseq, not the other way around, and define the NFData instances for the types in the containers package, in the containers package. Discussion deadline: 2 weeks.

11 28

Proposal: Add Control.Exception.allowInterrupt
by Simon Marlow 08 Jan '11

08 Jan '11

Ticket: http://hackage.haskell.org/trac/ghc/ticket/4857 This proposal is to add the following function to Control.Exception: -- | When invoked inside 'mask', this function allows a blocked -- asynchronous exception to be raised, if one exists. It is -- equivalent to performing an interruptible operation (see -- #interruptible#), but does not involve any actual blocking. -- -- When called outside 'mask', or inside 'uninterruptibleMask', this -- function has no effect. allowInterrupt :: IO () allowInterrupt = unsafeUnmask $ return () The above is almost the entire implementation modulo imports, so I didn't bother attaching a patch to the ticket. unsafeUnmask is not exported by Control.Exception, it is an internal function from GHC.IO. Some discussion leading up to this can be found in http://hackage.haskell.org/trac/ghc/ticket/3837. Discussion period: 3 weeks (until 12 Jan 2011) Cheers, Simon

3 4

Proposal: Deprecate and remove Prelude.catch and System.IO.Error.{catch,try}
by Ian Lynagh 05 Jan '11

05 Jan '11

Hi all, Deprecate and remove Prelude.catch and System.IO.Error.{catch,try} http://hackage.haskell.org/trac/ghc/ticket/4865 Prelude and System.IO.Error both export an old version of catch, which only catches IOError's, and System.IO.Error additionally exports try with the same problem. These exports are annoying for people who want to use the modern exception handling functions in Control.Exception, as you need to explicitly either import the Prelude with catch hidden, or give the module of the function you want to use. They may also be confusing for beginners, who may not expect to have to use anything other than the catch function in the default scope to catch all exceptions. I believe these functions are only there for historical reasons, and are old cruft that we should tidy up, so I propose that in the base package that comes with GHC 7.2 we deprecate these old functions, and in 7.4 we remove them. Suggested deadline: 24 Jan 2011. Thanks Ian

11 24