March 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

Stop using "Int" for microsecond delays in "base"
by Paul Johnson 21 Apr '11

21 Apr '11

The "base" library has the "threadDelay" primitive, which takes an Int argument in microseconds. Unfortunately this means that the longest delay you can get on a 32 bit machine with GHC is just under 36 minutes (2^31 uSec), and a hypothetical compiler that only used 30 bit integers (as per the standard) would get under 10 minutes. It is a bit tricky to write general-purpose libraries with this. I think that there should be a type Delay = Int64 declaration, and that threadDelay and related functions should take that as an argument type. Paul.

17 31

How to contact OpenGL package maintainer (where is Sven?)
by Jason Dagit 18 Apr '11

18 Apr '11

I sent the message below to Haskell-Cafe about a week ago. I got one response saying that Sven has disappeared in the past but reappeared when updates were necessary. I still haven't heard from Sven. Now I'm widening my search. My original email to Sven was on March 11th. It looks like the OpenGL packages on hackage[1,2,3,4] have not been updated in some time. No updates later than Oct 2009. I tried to email Sven directly using the email address listed on hackage but after over two weeks I still haven't heard from him. I sent some patches to the opengl list about a week ago but I noticed that Sven hasn't posted on that list since Oct 2009 when he released the current version of OpenGLRaw. None of the public darcs repos have patches newer than Oct 2009. Also, the homepage url listed in the packages is a 404: http://www.haskell.org/HOpenGL/ My concern is that Sven has disappeared for some reason. I hope he's well. He has always done top notch work in the past maintaining these libraries. Perhaps he's simply busy or lost interest? Does anyone know if he was looking for a new maintainer? Perhaps you've heard from him more recently than Oct 2009? If a new maintainer is needed, I would consider nominating myself :) Thanks, Jason [1] http://hackage.haskell.org/package/OpenGLRaw [2] http://hackage.haskell.org/package/OpenGL [3] http://hackage.haskell.org/package/GLURaw [4] http://hackage.haskell.org/package/GLUT

6 15

Proposal: Faster conversion between Rational and Double/Float
by Daniel Fischer 15 Apr '11

15 Apr '11

Currently, the conversions between Rational and Double resp. Float are rather slow: Converting 10,000 (pseudo-random) Doubles (from an unboxed array) to Floats and summing: Range -1e308 to 1e308: - double2Float: mean: 4.343703 ms, lb 4.324399 ms, ub 4.382361 ms, ci 0.950 - uncurry encodeFloat . decodeFloat: mean: 6.449336 ms, lb 6.427503 ms, ub 6.488190 ms, ci 0.950 - fromRational . toRational: mean: 875.3696 ms, lb 874.4413 ms, ub 876.6326 ms, ci 0.950 Range -1e37 to 1e37: - double2Float: mean: 547.6073 us, lb 544.3635 us, ub 559.5245 us, ci 0.950 - uncurry encodeFloat . decodeFloat: mean: 2.754600 ms, lb 2.749209 ms, ub 2.768121 ms, ci 0.950 - fromRational . toRational: mean: 287.4107 ms, lb 286.9602 ms, ub 288.0782 ms, ci 0.950 So all conversions suffer from large/out of range values, the primop most. The conversion via fromRational . toRational takes 200 - 500 times as long (subtracting array reads and addition, it would probably be much more for the conversion itself). The conversion via the proposed new implementations of toRational and fromRational took - large range: mean: 10.89560 ms, lb 10.86049 ms, ub 10.97370 ms, ci 0.950 - small range: mean: 7.015212 ms, lb 6.993312 ms, ub 7.068088 ms, ci 0.950 It suffers much less from large/out of range values and is 40 - 80 times faster than the old (probably a little more, subtracting array reads and additions). Converting 10,000 Floats to Doubles: - float2Double: mean: 540.6598 us, lb 539.0135 us, ub 545.1019 us, ci 0.950 - uncurry encodeFloat . decodeFloat: mean: 1.886183 ms, lb 1.882036 ms, ub 1.896018 ms, ci 0.950 - fromRational . toRational: mean: 280.6127 ms, lb 280.2228 ms, ub 281.1654 ms, ci 0.950 - new implementation: mean: 5.909890 ms, lb 5.892503 ms, ub 5.961752 ms, ci 0.950 ==================================================== One of the key factors for a fast fromRational is a fast integer logarithm to base 2. Since GHC can be built with integer-gmp or integer-simple and a fast implementation requires exploiting the low-level representation of Integers, I deemed it better to add modules to those packages implementing logarithms than adding different source directories to base to choose the appropriate one based on a flag, therefore in addition to the patch to base, this proposal includes patches to integer-gmp and to integer-simple, providing some integer logarithm functions. All functions have been tested to satisfy the appropriate conditions (fromRational (toRational x) == x for x Float/Double not NaN; toRational/fromRational yield the same values as the old implementation; base ^ integerLogBase base num <= num && num < base ^ (integerLogBase base num + 1) for base > 1, num > 0), both with pseudo-random input and selected special cases. The patches have been validated against ghc-7.1.20110329 (no unexpected failures in the testsuite which aren't identical without the patches). Since I have a 32-bit system, it is conceivable that I have a glitch in the 64-bit code, I'd appreciate testing. Summary: I propose - adding modules implementing integer logarithm functions to integer-gmp and integer-simple - changing the implementation of toRational and fromRational for Double and Float using those to become significantly faster. Period of discussion: two weeks (until 14th April). Cheers, Daniel

3 4

ANNOUNCE: incremental-parser library package
by Mario Blažević 14 Apr '11

14 Apr '11

The first version of incremental-parser has been released on Hackage [1]. It's yet another parser combinator library, providing the usual set of Applicative and Monad combinators. Apart from this, it has three twists that make it unique. First, the parser is incremental. That means it can be fed its input in chunks, and in proper circumstances it can also provide the parsed output in chunks. For this to be possible the result type must be a Monoid. The complete parsing result is then a concatenation of the partial results. In order to make the incremental parsing easier, the combinator set is optimized for monoidal results. The usual combinator many1, for example, assumes the result type is a monoid and concatenates its components instead of constructing a list. In Parsec: > many1 :: Stream s m t => ParsecT s u m a -> ParsecT s u m [a] In incremental-parser: > many1 :: (Monoid s, Monoid r) => Parser s r -> Parser s r The second weirdness is that the the parser is generic in its input stream type, but this type is parameterized in a holistic way. There is no separate token type. Primitive parsers that need to peek into the input require its type to be an instance of a monoid subclass. In Parsec: > string :: Stream s m Char => String -> ParsecT s u m String > char :: Stream s m Char => Char -> ParsecT s u m Char > anyToken :: (Stream s m t, Show t) => ParsecT s u m t In Attoparsec: > string :: ByteString -> Parser ByteString > word8 :: Word8 -> Parser Word8 > anyWord8 :: Parser Word8 In incremental-parser: > string :: (LeftCancellativeMonoid s, MonoidNull s) => s -> Parser s s > token :: (Eq s, FactorialMonoid s) => s -> Parser s s > anyToken :: FactorialMonoid s => Parser s s The monoid subclasses referenced above provide methods for analyzing and subdividing the input stream. The classes are not particularly demanding, and any reasonable input stream should be able to accommodate them easily. The library comes with instances for lists, ByteString, and Text. > class Monoid m => MonoidNull m where > mnull :: m -> Bool > class Monoid m => LeftCancellativeMonoid m where > mstripPrefix :: m -> m -> Maybe m > class Monoid m => FactorialMonoid m where > factors :: m -> [m] > primePrefix :: m -> m > ... Finally, the library being implemented on the basis of Brzozowski derivatives, it can provide both the symmetric and the left-biased choice, <|> and <<|>. This is the same design choice made by Text.ParserCombinators.ReadP and uu-parsinglib. Parsec and its progeny on the other hand provide only the faster left-biased choice, at some cost to the expressiveness of the combinator language. [1] http://hackage.haskell.org/package/incremental-parser-0.1

6 7

Proposal: Improve the API for TChan, TMVar, and TVar
by wren ng thornton 08 Apr '11

08 Apr '11

I've found the following functions helpful for working with STM. Some of them are just filling out the API so that TVars, TMVars, and IORefs match better. And all the non-TVar functions can be optimized considerably by including them in the STM library rather than defining them externally. The implementations are obvious, so I'll just include the types here; see the patch if you're interested. -- | Non-blocking version of 'readTChan'. tryReadTChan :: TChan a -> STM (Maybe a) -- | Get the next value from the 'TChan' without removing it, -- blocking if the channel is empty. peekTChan :: TChan a -> STM a -- | Non-blocking version of 'peekTChan'. tryPeekTChan :: TChan a -> STM (Maybe a) -- | Non-blocking version of 'readTMVar'. tryReadTMVar :: TMVar a -> STM (Maybe a) -- | Like 'modifyIORef' but for 'TVar'. modifyTVar :: TVar a -> (a -> a) -> STM () -- | Strict version of 'modifyTVar'. modifyTVar' :: TVar a -> (a -> a) -> STM () -- | Like 'swapTMVar' but for 'TVar'. swapTVar :: TVar a -> a -> STM a Discussion period: 2 weeks. -- Live well, ~wren

4 10

Conversion to git
by Ian Lynagh 06 Apr '11

06 Apr '11

Hi all, The latest GHC git conversion plan is to convert GHC and all associated repos to git on: *** Tuesday, March the 15th *** In some cases this will mean simply converting the master repos, while in others it'll mean setting up git (lagging) mirrors for the GHC build to use. We've made a list of which repos we suggest should be converted, and which should be mirrored, here: http://hackage.haskell.org/trac/ghc/wiki/DarcsConversion#Planforlibraries Can you please let us know if you think any of the repos have been put in the wrong category? Thanks Ian

5 10

The System Event Manager
by Bas van Dijk 04 Apr '11

04 Apr '11

Hello, When you want to use the system event manager (the one started by the RTS) you currently have to do something like this: ----------------------------------------------------------------------- {-# LANGUAGE ForeignFunctionInterface #-} import System.Event (EventManager) import GHC.Conc.Sync (sharedCAF) import Foreign.Ptr (Ptr) import Data.IORef (IORef, newIORef, readIORef) import System.IO.Unsafe (unsafePerformIO) main = do Just mgr <- readIORef eventManager ... eventManager :: IORef (Maybe EventManager) eventManager = unsafePerformIO $ do em <- newIORef Nothing sharedCAF em getOrSetSystemEventThreadEventManagerStore {-# NOINLINE eventManager #-} foreign import ccall unsafe "getOrSetSystemEventThreadEventManagerStore" getOrSetSystemEventThreadEventManagerStore :: Ptr a -> IO (Ptr a) ----------------------------------------------------------------------- What about abstracting this ugliness in a function: getSystemEventManager :: IO EventManager getSystemEventManager = do Just mgr <- readIORef eventManager return mgr I'm not entirely comfortable about the partial pattern match. I guess it fails when the program is linked with the non-threaded RTS. Can we use #ifdef THREADED_RTS here? I'm also not sure from which module to export this function. The attached patch defines it in and exports it from System.Event.Thread. It also exports it from the public System.Event. However maybe it's better to export it from GHC.Conc instead. What do you think? Regards, Bas

2 3