February 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

Assertion in IO monad
by Mitar 29 Mar '11

29 Mar '11

Hi! In Haskell there is difference between throw and throwIO. Because of that I searched for a way to assure ordering in a similar manner of my assertions. But I have not found any. Wouldn't it be useful to have also assertIO counterpart of assert? I would propose "Bool -> IO ()" type. Mitar

4 7

Faster timeout but is it correct?
by Bas van Dijk 25 Mar '11

25 Mar '11

Dear all, I wrote a faster implementation for System.Timeout.timeout but wonder whether it's correct. It would be great if someone can review the code. The implementation comes with a tiny Criterion benchmark: darcs get http://bifunctor.homelinux.net/~bas/bench_timeouts/ On ghc-7.0.1 with -O2 the following benchmark, which always times out, doesn't show a difference with the current timeout: timeout 1 (threadDelay 1000000) However the following benchmark, which never times out, shows nice speedups for both a non-threaded and a threaded version: timeout 1000000 (return ()) non-threaded: 3.6 faster threaded: 10.8 faster I suspect the reason why my timeout is faster is that I use only one 'catch' while the original uses two: handleJust and bracket. I have to admit that my implementation is more complex and more fragile than the original. That's why I'm not sure of it's correctness yet: newtype Timeout = Timeout Unique deriving (Eq, Typeable) instance Show Timeout where show _ = "<<timeout>>" instance Exception Timeout timeout :: Int -> IO a -> IO (Maybe a) timeout n f | n < 0 = fmap Just f | n == 0 = return Nothing | otherwise = do myTid <- myThreadId timeoutEx <- fmap Timeout newUnique uninterruptibleMask $ \restore -> do tid <- restore $ forkIO $ threadDelay n >> throwTo myTid timeoutEx let handle e = case fromException (e :: SomeException) of Just timeoutEx' | timeoutEx' == timeoutEx -> return Nothing _ -> killThread tid >> throwIO e mb <- restore (fmap Just f) `catch` handle killThread tid return mb If nobody proves it incorrect I will make a patch for the base library. Regards, Bas

6 35

Proposal: add ByteString support to unix:System.Posix.IO API
by wren ng thornton 07 Mar '11

07 Mar '11

Hello all, I've written variants of the System.Posix.IO API for strict and lazy ByteStrings which are currently lingering in their own unpublished package[1]. It's silly to have a separate package for just four functions, so I'd like to see it combined into the unix package. I don't have access to create a new ticket with the patch, but it's available at [2]. Discussion time: 2 weeks. [1] darcs: http://community.haskell.org/~wren/bytestring-unix haddock: http://community.haskell.org/~wren/bytestring-unix/dist/doc/html/bytestring… [2] Darcs patch: http://community.haskell.org/~wren/bytestring-unix/bytestring-unix-0.1.0.dp… -- Live well, ~wren

6 15

Re: Proposal: add ByteString support to unix:System.Posix.IO API
by wren ng thornton 04 Mar '11

04 Mar '11

On 2/28/11 12:28 PM, Johan Tibell wrote: > On Mon, Feb 28, 2011 at 9:20 AM, Bryan O'Sullivan<bos(a)serpentine.com> wrote: >> On Sun, Feb 27, 2011 at 9:18 PM, wren ng thornton<wren(a)freegeek.org> wrote: >>> >>> I've written variants of the System.Posix.IO API for strict and lazy >>> ByteStrings which are currently lingering in their own unpublished >>> package[1]. It's silly to have a separate package for just four functions, >>> so I'd like to see it combined into the unix package. I don't have access to >>> create a new ticket with the patch, but it's available at [2]. >> >> I think that the strict bytestring version should just replace the current >> function in System.Posix.IO, and the lazy version should not go in at all. >> This is the approach taken by the network package, and it's cleanest. > > Thanks for working on this Wren. > > I agree with Bryan's point. So then what would become of the string variants? Backwards compatibility and all... not _everyone_ uses ByteStrings yet. Also, FWIW, the real impetus behind writing these was to deal with lazy ByteStrings, since that's what one of my dependencies uses[1]. It seems like a common enough situation that it should be handled directly. Forcing people to call (BS.concat . BL.toChunks) first muddies up the code and introduces additional copying, whereas making people use (mapM_ fdWrite . BL.toChunks) is still rather messy and it's buggy in the face of partial writes. For network usage I agree that the strict-only approach is clean and effective. For general purpose writing to Fds, I'm not so sure. [1] http://hackage.haskell.org/packages/archive/protocol-buffers/1.8.0/doc/html… -- Live well, ~wren

11 22

add Data.Bool.ifThenElse
by Henning Thielemann 01 Mar '11

01 Mar '11

If I activate RebindableSyntax in GHC-7.0, I have to provide a function named ifThenElse. How about a default implementation in Data.Bool that is equivalent to classical if-then-else? So far, I only use RebindableSyntax for overloaded number literals.

3 3