January 2011 - Libraries

Proposal: Add newUniqueSTM to Data.Unique
by Edward Kmett 27 Apr '12

27 Apr '12

Data.Unique's newUnique uses atomically internally to update a TVar. Consequently attempting to "unsafeIOToSTM newUnique" to allocate a Unique within an STM transaction blows you sky high. The proposal is to split the definition of newUnique into: newUnique = atomically newUniqueSTM and expose newUniqueSTM. Alternately, since bug #3838 has been resolved, we could revert to using an IORef, which would avoid the wart of having us have an overtly IO action detonate because of an internal implementation detail of using STM. Since, there are two paths forward, I haven't put forward a patch, but wanted to open a discussion. Discussion Period: 2 weeks. -Edward Kmett

6 12

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

darcs patch: Expand and clarify MVar documentation.
by Edward Z. Yang 25 Feb '11

25 Feb '11

1 patch for repository http://darcs.haskell.org/packages/base: Sun Jan 16 19:23:34 GMT 2011 Edward Z. Yang <ezyang(a)mit.edu> * Expand and clarify MVar documentation.

2 1

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

Re: parsec3 vs parsec-3.x
by Roman Cheplyaka 02 Feb '11

02 Feb '11

* Christian Maeder <Christian.Maeder(a)dfki.de> [2011-01-31 09:34:47+0100] > > Perhaps I missed something. Can someone please explain why do we have to > > have two different third parsecs? Should one of them be deprecated? When > > would a user prefer one to another? > > parsec-2 (and possibly its compatibility layer) may be deprecated or > superseded at some stage. > > > I read the description of parsec3 package on hackage, it tries to give > > some explanation, but still: > > > > 1. It's not clear why "you may want to develop your code using this > > subset of parsec3 modules". What advantage does it give? > > The parsec3 package only ensures that you are not using the > compatibility layer for parsec2 given by the modules > Text.ParserCombinators.Parsec*, because parsec3 code developed with > these modules might not work with parsec2 or parsec-2.x. >From the description of parsec3 on hackage [...] I do not recommend to unconditionally use parsec3 as dependency in cabal files of packages for hackage. But you may want to develop your code using this subset of parsec3 modules and finally change the dependency from parsec3 to parsec-3.1.1 [...] I got an impression that parsec3 should be used only during the development, not in a released package. But as a developer of a package I have pretty good understanding of what modules I'm using, and if in doubt I can simply run "grep -r Text.ParserCombinators.Parsec ." Maybe it would become more clear if you elaborate on who and how exactly might benefit from this package? Thanks, Roman -- Roman I. Cheplyaka :: http://ro-che.info/ Don't worry what people think, they don't do it very often. In-Reply-To: <4D467427.1000104(a)dfki.de>

3 7

Applicative and parsec3
by Kazu Yamamoto 31 Jan '11

31 Jan '11

Hello, I'm using parsec3 with the applicative style. Since the functions in Control.Applicative and parsec3 conflicts, I need to use the "hiding" keyword as follows: import Control.Applicative hiding (many,optional,(<|>)) import Text.Parsec This is inconvenient for me. I would like to use them as follows: import Control.Applicative import Text.Parsec Christian, the maintainer of parsec3, told me that it is possible to use the functions of Control.Applicative in parsec3 instead of implementing its own functions. But (<|>) of parsec3 is "infixr 1" while that of Control.Applicative is "infixl 3". This may be an issue. Any ideas to solve this issue? --Kazu

8 15