January 2011 - Libraries

Library proposal: add a Location interface for element-wise operations on Data.Map (#4887)
by Ross Paterson 15 Jan '11

15 Jan '11

This is a variant of a suggestion by apfelmus: http://www.haskell.org/pipermail/libraries/2010-September/014510.html To avoid proliferation of variants of element-wise operations, the idea is to split these operations into two phases mediated by a new Location type, so that users can do whatever they like between these phases. Documentation is here: http://code.haskell.org/~ross/containers_doc/Data-Map.html#3 This adds a type and 9 functions to the interface, but makes possible monadic updates and much more. As an illustration, the file MapOps.hs attached to the ticket gives definitions of 30 of the public functions of Data.Map in terms of the new interface. At least in the case of insert, this definition is slightly faster than the current one. Discussion period: 4 weeks (to 4 February)

11 25

multiple cabal files in one directory?
by Kathleen Fisher 13 Jan '11

13 Jan '11

Hi, Is it possible to have a directory with multiple cabal files, telling cabal which file to use for a given install request by passing in a flag, say something like: >cabal install -f pads.cabal or >cabal install -f forest.cabal In other words, something like the -f option in make. I looked through the cabal documentation, but didn't see an option for specifying the cabal file to use. Did I just fail to see the proper flag? or does it not exist? If it doesn't, is that just because it hasn't been implemented, or is there a Good Reason? Thanks for any pointers and explanations! Kathleen

10 25

Re: Misleading MVar documentation
by Edward Z. Yang 13 Jan '11

13 Jan '11

Ok, here is an updated doc patch. I've also added a substantial introduction section. diff -rN -u old-base/Control/Concurrent/MVar.hs new-base/Control/Concurrent/MVar.hs --- old-base/Control/Concurrent/MVar.hs 2011-01-13 16:26:59.000000000 +0000 +++ new-base/Control/Concurrent/MVar.hs 2011-01-13 16:27:00.000000000 +0000 @@ -9,7 +9,103 @@ -- Stability : experimental -- Portability : non-portable (concurrency) -- --- Synchronising variables +-- An @'MVar' t@ is mutable location that is either empty or contains a +-- value of type @t@. It has two fundamental operations: 'putMVar' +-- which fills an 'MVar' if it is empty and blocks otherwise, and +-- 'takeMVar' which empties an 'MVar' if it is full and blocks +-- otherwise. They can be used in multiple different ways: +-- +-- 1. As synchronized mutable variables, +-- 2. As channels, with 'takeMVar' and 'putMVar' as receive and send, and +-- 3. As a binary semaphore @'MVar' ()@, with 'takeMVar' and 'putMVar' as +-- wait and signal. +-- +-- They were introduced in the paper "Concurrent Haskell" by Simon +-- Peyton Jones, Andrew Gordon and Sigbjorn Finne, though some details +-- of their implementation have since then changed (in particular, a +-- put on a full MVar used to error, but now merely blocks.) +-- +-- * Applicability +-- +-- 'MVar's offer more flexibility than 'IORef's, but less flexibility +-- than 'STM'. They are appropriate for building synchronization +-- primitives and performing simple interthread communication; however +-- they are very simple and susceptible to race conditions, deadlocks or +-- uncaught exceptions. Do not use them if you need perform larger +-- atomic operations such as reading from multiple variables: use 'STM' +-- instead. +-- +-- In particular, the "bigger" functions in this module ('readMVar', +-- 'swapMVar', 'withMVar', 'modifyMVar_' and 'modifyMVar') are simply +-- compositions a 'takeMVar' followed by a 'putMVar' with exception safety. +-- These only have atomicity guarantees if all other threads +-- perform a 'takeMVar' before a 'putMVar' as well; otherwise, they may +-- block. +-- +-- * Fairness +-- +-- No process can be blocked indefinitely on an 'MVar' unless another +-- process holds that 'MVar' indefinitely. One usual implementation of +-- this fairness guarantee is that processed blocked on an 'MVar' are +-- served in a first-in-first-out fashion, but this is not guaranteed +-- in the semantics. +-- +-- * Gotchas +-- +-- Like many other Haskell data structures, 'MVar's are lazy. This +-- means that if you place an expensive unevaluated thunk inside an +-- 'MVar', it will be evaluated by the thread that consumes it, not the +-- thread that produced it. Be sure to 'evaluate' values to be placed +-- in an 'MVar' to the appropriate normal form, or utilize a strict +-- MVar provided by the strict-concurrency package. +-- +-- * Example +-- +-- Consider the following concurrent data structure, a skip channel. +-- This is a channel for an intermittent source of high bandwidth +-- information (for example, mouse movement events.) Writing to the +-- channel never blocks, and reading from the channel only returns the +-- most recent value, or blocks if there are no new values. Multiple +-- readers are supported with a @dupSkipChan@ operation. +-- +-- A skip channel is a pair of 'MVar's: the second 'MVar' is a semaphore +-- for this particular reader: it is full if there is a value in the +-- channel that this reader has not read yet, and empty otherwise. +-- +-- @ +-- data SkipChan a = SkipChan (MVar (a, [MVar ()])) (MVar ()) +-- +-- newSkipChan :: IO (SkipChan a) +-- newSkipChan = do +-- sem <- newEmptyMVar +-- main <- newMVar (undefined, [sem]) +-- return (SkipChan main sem) +-- +-- putSkipChan :: SkipChan a -> a -> IO () +-- putSkipChan (SkipChan main _) v = do +-- (_, sems) <- takeMVar main +-- putMVar main (v, []) +-- mapM_ (\sem -> putMVar sem ()) sems +-- +-- getSkipChan :: SkipChan a -> IO a +-- getSkipChan (SkipChan main sem) = do +-- takeMVar sem +-- (v, sems) <- takeMVar main +-- putMVar main (v, sem:sems) +-- return v +-- +-- dupSkipChan :: SkipChan a -> IO (SkipChan a) +-- dupSkipChan (SkipChan main _) = do +-- sem <- newEmptyMVar +-- (v, sems) <- takeMVar main +-- putMVar main (v, sem:sems) +-- return (SkipChan main sem) +-- @ +-- +-- This example was adapted from the original Concurrent Haskell paper. +-- For more examples of 'MVar's being used to build higher-level +-- synchronization primitives, see 'Control.Concurrent.Chan' and +-- 'Control.Concurrent.QSem'. -- ----------------------------------------------------------------------------- @@ -56,7 +152,9 @@ {-| This is a combination of 'takeMVar' and 'putMVar'; ie. it takes the value - from the 'MVar', puts it back, and also returns it. + from the 'MVar', puts it back, and also returns it. This function + is atomic only if there are no other producers (i.e. threads calling + 'putMVar') for this 'MVar'. -} readMVar :: MVar a -> IO a readMVar m = @@ -67,9 +165,8 @@ {-| Take a value from an 'MVar', put a new value into the 'MVar' and - return the value taken. Note that there is a race condition whereby - another process can put something in the 'MVar' after the take - happens but before the put does. + return the value taken. This function is atomic only if there are + no other producers for this 'MVar'. -} swapMVar :: MVar a -> a -> IO a swapMVar mvar new = @@ -79,10 +176,11 @@ return old {-| - 'withMVar' is a safe wrapper for operating on the contents of an - 'MVar'. This operation is exception-safe: it will replace the + 'withMVar' is an exception-safe wrapper for operating on the contents + of an 'MVar'. This operation is exception-safe: it will replace the original contents of the 'MVar' if an exception is raised (see - "Control.Exception"). + "Control.Exception"). However, it is only atomic if there are no + other producers for this 'MVar'. -} {-# INLINE withMVar #-} -- inlining has been reported to have dramatic effects; see @@ -96,9 +194,11 @@ return b {-| - A safe wrapper for modifying the contents of an 'MVar'. Like 'withMVar', - 'modifyMVar' will replace the original contents of the 'MVar' if an - exception is raised during the operation. + An exception-safe wrapper for modifying the contents of an 'MVar'. + Like 'withMVar', 'modifyMVar' will replace the original contents of + the 'MVar' if an exception is raised during the operation. This + function is only atomic if there are no other producers for this + 'MVar'. -} {-# INLINE modifyMVar_ #-} modifyMVar_ :: MVar a -> (a -> IO a) -> IO ()

1 0

cabal install QuickCheck
by Christian Maeder 10 Jan '11

10 Jan '11

Hi, I was recently puzzled by the fact that I got QuickCheck-1.2.0.1 via cabal although QuickCheck-2.1.1.1 is in the current haskell-platform-2010.2.0.0. Shouldn't hackage be adjusted? Cheers Christian

4 4

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

packages with orphaned instances only
by Christian Maeder 10 Jan '11

10 Jan '11

Hi, referring to previous messages about QuickCheck and Johan's proposal about moving instances I wonder how many of us have created obviously orphaned "Arbitrary" instances for container data types? Maybe indeed separate packages with (orphaned) instances only should be created for re-use. I haven't seen such packages on hackage, yet. And maybe such packages should be clearly recognizable. So is this a bad idea? Cheers Christian

9 18

[PATCH] [rfc] Network.Socket: Add recvBuf
by Simon Horman 09 Jan '11

09 Jan '11

recently I have been looking into a latency-gap between the C and Haskell implementations of a TCP-echo One issue that has come up is that recvBufFrom calls getpeername() for each successful recvfrom(). This is unnecessary in the context of the code that I am working with as the result is discarded. My proposed solution to this is to implement recvBuf. I apologise in advance for my rudimentary Haskell skills. --- Network/Socket.hsc | 57 ++++++++++++++++++++++++++++++++++----------------- 1 files changed, 38 insertions(+), 19 deletions(-) diff --git a/Network/Socket.hsc b/Network/Socket.hsc index 21d83ac..13a94c2 100644 --- a/Network/Socket.hsc +++ b/Network/Socket.hsc @@ -81,6 +81,7 @@ module Network.Socket -- ** Sending and receiving -- $sendrecv , recv + , recvBuf , recvBufFrom , recvFrom , recvLen @@ -662,16 +663,10 @@ recvFrom sock nbytes = str <- peekCStringLen (ptr, len) return (str, len, sockaddr) --- | Receive data from the socket, writing it into buffer instead of --- creating a new string. The socket need not be in a connected --- state. Returns @(nbytes, address)@ where @nbytes@ is the number of --- bytes received and @address@ is a 'SockAddr' representing the --- address of the sending socket. --- -- NOTE: blocking on Windows unless you compile with -threaded (see -- GHC ticket #1129) -recvBufFrom :: Socket -> Ptr a -> Int -> IO (Int, SockAddr) -recvBufFrom sock@(MkSocket s family _stype _protocol _status) ptr nbytes +recvBufFrom' :: Socket -> Ptr a -> Int -> IO (Int, Ptr SockAddr) +recvBufFrom' sock@(MkSocket s family _stype _protocol _status) ptr nbytes | nbytes <= 0 = ioError (mkInvalidRecvArgError "Network.Socket.recvFrom") | otherwise = withNewSockAddr family $ \ptr_addr sz -> do @@ -687,17 +682,41 @@ recvBufFrom sock@(MkSocket s family _stype _protocol _status) ptr nbytes let len' = fromIntegral len if len' == 0 then ioError (mkEOFError "Network.Socket.recvFrom") - else do - flg <- sIsConnected sock - -- For at least one implementation (WinSock 2), recvfrom() ignores - -- filling in the sockaddr for connected TCP sockets. Cope with - -- this by using getPeerName instead. - sockaddr <- - if flg then - getPeerName sock - else - peekSockAddr ptr_addr - return (len', sockaddr) + else return (len', ptr_addr) + +-- | Receive data from the socket, writing it into buffer instead of +-- creating a new string. The socket need not be in a connected +-- state. Returns @(nbytes, address)@ where @nbytes@ is the number of +-- bytes received and @address@ is a 'SockAddr' representing the +-- address of the sending socket. +-- +-- NOTE: blocking on Windows unless you compile with -threaded (see +-- GHC ticket #1129) +recvBufFrom :: Socket -> Ptr a -> Int -> IO (Int, SockAddr) +recvBufFrom sock ptr nbytes = do + (len, ptr_addr) <- recvBufFrom' sock ptr nbytes + flg <- sIsConnected sock + -- For at least one implementation (WinSock 2), recvfrom() ignores + -- filling in the sockaddr for connected TCP sockets. Cope with + -- this by using getPeerName instead. + sockaddr <- + if flg then + getPeerName sock + else + peekSockAddr ptr_addr + return (len, sockaddr) + +-- | Receive data from the socket, writing it into buffer instead of +-- creating a new string. The socket need not be in a connected +-- state. Returns @(nbytes)@ where @nbytes@ is the number of +-- bytes received. +-- +-- NOTE: blocking on Windows unless you compile with -threaded (see +-- GHC ticket #1129) +recvBuf :: Socket -> Ptr a -> Int -> IO Int +recvBuf sock ptr nbytes = do + (len, ptr_addr) <- recvBufFrom' sock ptr nbytes + return len ----------------------------------------------------------------------------- -- send & recv -- 1.7.2.3

2 2

Data.Monoid.First and Data.Monoid.Last
by Louis Wasserman 09 Jan '11

09 Jan '11

Is there a reason that Data.Monoid.First and Data.Monoid.Last aren't also instances of Functor, Applicative, Alternative, Monad, MonadPlus? I find those instances quite useful. Louis Wasserman wasserman.louis(a)gmail.com http://profiles.google.com/wasserman.louis

2 1

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

Re: Proposal: Change to library proposal process
by Howard B. Golden 08 Jan '11

08 Jan '11

On 06 Jan 2011 11:32:45 +0000, Simon Marlow <marlowsd(a)gmail.com> wrote: > The changes being proposed by Greg and Johan, as I understand it, would > amount to the following. I'm willing to give it a try; we can always go > back if it doesn't work out. > > - maintainers are empowered to make API changes. > > - no formal review process for API changes, although there is an > expectation that non-trivial changes would still be discussed on > the list beforehand. >From my experience upgrading Gentoo's Haskell distribution, I would like to suggest a bit more structure than this. API changes can wreak havoc with many packages. Therefore, I believe that we should _strongly_encourage_ upward compatibility in API changes. This doesn't require that APIs remain static, nor need it cause a lot of difficulty for maintainers, if we _encourage_ smooth migration to the new API. One possible approach would be to add conditional compilation directives so the new and old APIs can co-exist initially. This would provide an easy workaround for packages that depend on the old API. There may be better methods than this, but this is always an option. Alternatively, we should try to develop adapter libraries (e.g., old-time and old-locale) so old code can still be compiled with minimal modification. There are still many packages that depend on base-3 and the switch to ghc-7.0 and base-4.3 breaks them. From the perspective of an enterprise developer the current situation is a show-stopper. In order to gain more enterprise penetration we need to make upgrades less painful. Cheers, Howard

3 3