December 2010 - Libraries

Suggested new function for System.Process - robustReadProcessWithExitCode
by Andrew Miller 05 Jan '11

05 Jan '11

Hi, I include my proposal for a new function, for System.Process , robustReadProcessWithExitCode, below. Best wishes, Andrew Miller Motivation for change: using readProcessWithExitCode risks terminating the program due to uncaught IOException (ResourceExhausted) if the input string is not read entirely by the new process before the new process exits, because readProcessWithExitCode will attempt to write to a process that doesn't exist. Often, it is the exit code and standard input and standard error that matters to a programmer, and not whether a process read all the input. There is therefore a case for a function like readProcessWithExitCode which is robust to the new process exiting before all input is read. Suggested implementation: {- | robustReadProcessWithExitCode creates an external process, reads its standard output and standard error strictly, waits until the process terminates, and then returns the 'ExitCode' of the process, the standard output, and the standard error. 'robustReadProcessWithExitCode' is a fairly simple wrapper around 'createProcess'. Constructing variants of these functions is quite easy: follow the link to the source code to see how 'robustReadProcessWithExitCode' is implemented. 'robustReadProcessWithExitCode' differs from 'readProcessWithExitCode' because it ignores IOExceptions encountered when writing the input to the new process. This can be useful if you don't know if the process reads all your input, but you want to get the output and exit code even if it exits before reading all input. -} robustReadProcessWithExitCode :: FilePath -- ^ command to run -> [String] -- ^ any arguments -> String -- ^ standard input -> IO (ExitCode,String,String) -- ^ exitcode, stdout, stderr robustReadProcessWithExitCode cmd args input = do (Just inh, Just outh, Just errh, pid) <- createProcess (proc cmd args){ std_in = CreatePipe, std_out = CreatePipe, std_err = CreatePipe } outMVar <- newEmptyMVar -- fork off a thread to start consuming stdout out <- hGetContents outh _ <- forkIO $ C.evaluate (length out) >> putMVar outMVar () -- fork off a thread to start consuming stderr err <- hGetContents errh _ <- forkIO $ C.evaluate (length err) >> putMVar outMVar () -- now write and flush any input, ignoring errors when (not (null input)) $ C.handle ((\e -> return ()) :: (C.IOException -> IO ())) $ do hPutStr inh input; hFlush inh hClose inh -- done with stdin -- wait on the output takeMVar outMVar takeMVar outMVar hClose outh -- wait on the process ex <- waitForProcess pid return (ex, out, err)

3 2

(Co/Contra)Functor and Comonad
by Mario Blažević 31 Dec '10

31 Dec '10

Why are Cofunctor and Comonad classes not a part of the base library? I recently defined a data type (Control.Cofunctor.Ticker in monad-coroutine on Hackage) that happens to be a co-functor, or contra-functor if you prefer. In other words, it can implement the following function: > cofmap :: (a -> b) -> cf b -> cf a I wanted to define a proper instance for it, but to my surprise I discovered that I couldn't. Not only is the class not defined in base, the only package I could find on Hackage that defines it is category-extras. This is a huge package I'd rather not have as a dependency, so I opted not to declare any instance. Later on I found that this question has been raised before by *Conal Elliott*, nearly four years ago. http://www.haskell.org/pipermail/libraries/2007-January/006740.html The result was the TypeCompose package, which presents a decent solution. I still can't think of any harm in having a proper class declaration in the base library: if you don't need it, you don't need to know it. But without the class declaration in the base library (or in some other obvious package) every other released library must either lack the instance declarations or declare the class itself and risk clashes. This is not some obscure class you've never encountered, by the way: any "consumer" of data is a cofunctor. All regexp data types, for example, are cofunctor instances - or would be if there was a class to declare them instances of. The same question extends to Comonad. I am not too familiar with this area so there may be fewer potential instances of the class, but I remember there was quite a bit of buzz around comonads a few years ago. Judging by a cursory Hayoo search, if anything the situation is worse than with Cofunctor: there are multiple incompatible declarations of the class scattered in various libraries that need it: ad, category-extras, data-category, rope. There is also evidence of undeclared Comonad instances: see the ListZipper and value-supply libraries. So, is it time to add these two classes to the base library?

5 6

Proposal to add recvBuf and sendTo to Network.Socket
by Simon Horman 29 Dec '10

29 Dec '10

Hi, 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. For the sake of symmetry I think that it it would also make sense to add sendBuf, although I don't have any performance-based reasons for this. I have not yet considered what changes to the higher-level Network API would make sense in order allow getpeername-less recv and read. Before preparing patches - I have a crude one for testing that works - I would like to get an idea of if this change acceptable or not. And if so discuss which API calls might be appropriate to add.

3 4

Applicative instance for ST
by Daniel Peebles 29 Dec '10

29 Dec '10

Hi all, Strangely enough, ST has a Functor and a Monad instance, but no Applicative instance (I guess it was pre-Applicative). I propose to add one. It doesn't seem very controversial, but I guess a normal discussion period for these proposals is two weeks? Thanks, Dan

6 10

Functor => Applicative => Monad
by John Smith 23 Dec '10

23 Dec '10

I would like to formally propose that Monad become a subclass of Applicative, with a call for consensus by 1 February. The change is described on the wiki at http://haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal, and ticketed at http://hackage.haskell.org/trac/ghc/ticket/4834. As this would require a change to the prelude, it will presumably be necessary for GHC and the Haskell report to change in tandem. The Haskell' committee expects proposals to have been implemented before changing the standard, so I will propose this to Haskell' after it is accepted for GHC. Hopefully this will be sufficient to avoid a race condition.

5 8

Functor => Pointed => Applicative => Monad
by John Smith 22 Dec '10

22 Dec '10

Is there any intention to reorganise the standard class hierarchy, arranging them logically instead of in order of invention? I plagiarised the following example from http://stackoverflow.com/questions/1634911/can-liftm-differ-from-lifta and Trac: class Functor f where map :: (a -> b) -> f a -> f b class Functor f => Pointed f where pure :: a -> f a class Pointed f => Applicative f where (<*>) :: f (a -> b) -> f a -> f b (*>) :: f a -> f b -> f b (<*) :: f a -> f b -> f a class Applicative m => Monad m where (>>=) :: m a -> (a -> m b) -> m b (>>) :: m a -> m b -> m b join :: m (m a) -> m a f >>= x = join (fmap f x) m >> k = m >>= \_ -> k join x = x >>= id This would eliminate the necessity of declaring a Monad instance for every Applicative, and eliminate the need for sets of duplicate functions such as [fmap,liftM,map,liftA], [(<*>),ap], and [concat,join]. fail should be removed from Monad; a failed pattern match could error in the same way as is does for pure code. The only sensible uses for fail seem to be synonyms for mzero.

21 53

Proposal: Add Control.Concurrent.forkIOWithUnmask, deprecate forkIOUnmasked
by Simon Marlow 22 Dec '10

22 Dec '10

Ticket: http://hackage.haskell.org/trac/ghc/ticket/4858 We added forkIOUnmasked as part of the new asynchronous exceptions API in base 4.3.0.0 (GHC 7.0.1). Unfortunately, forkIOUnmasked isn't very useful: the computation in the child thread is executed in the unmasked state, so the child doesn't have a way to reliably set up an exception handler before an asynchronous exception is raised. This proposal is to replace forkIOUnmasked with forkIOWithUnmask: -- | Like 'forkIO', but the child thread is passed a function that can -- be used to unmask asynchronous exceptions. This function is -- typically used in the following way -- -- > ... mask_ $ forkIOWithUnmask $ \unmask -> -- > catch (unmask ...) handler -- -- so that the exception handler in the child thread is established -- with asynchronous exceptions masked, meanwhile the main body of -- the child thread is executed in the unmasked state. -- -- Note that the unmask function passed to the child thread should -- only be used in that thread; the behaviour is undefined if it is -- invoked in a different thread. -- forkIOWithUnmask :: ((forall a . IO a -> IO a) -> IO ()) -> IO ThreadId forkIOWithUnmask io = forkIO (io unsafeUnmask) forkIOUnmasked will be deprecated. Above is almost the entire implementation, hence I didn't bother attaching a patch to the ticket. 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

2 2

[darcs patch] filepath: normalise trailing dot
by Conrad Parker 21 Dec '10

21 Dec '10

Hi, the attached darcs patch modifies the behaviour of normalise to handle trailing dots in a path. The previous behaviour yielded this: Prelude System.FilePath> normalise "../." "../." Prelude System.FilePath> normalise ".././" ".././" Prelude System.FilePath> normalise ".././.." "../.." This patch modifies dropDots such that the check for (".":[]) only occurs once for the path, after which a driver function dropDots' is used which skips this check. Hence "." can be removed from the end of a longer path, but a path of just "." is unchanged. (my trac account is pending verification, I'll reply with a trac ticket # later if needed) cheers, Conrad.

4 7

Make Chan an instance of Eq
by Mitar 20 Dec '10

20 Dec '10

Hi! Chan should be an instance of Eq. I opened a ticket for this with a patch: http://hackage.haskell.org/trac/ghc/ticket/4526 Mitar

4 16

Proposal: Add tryReadChan to Chan
by Mitar 13 Dec '10

13 Dec '10

Hi! Now that isEmptyChan is deprecated (#4154) it would be useful to add tryReadChan. It seems it is possible to define it so that it does not block like isEmptyChan. This is because semantics is a bit different: tryReadChan is allowed to return Nothing also when Chan is non-empty, but it would block. Contrary, isEmptyChan is expected that it would return False only if Chan is really empty. I have defined also two new MVar functions which helped me implementing tryReadChan: tryReadMVar and tryModifyMVar. Probably it would be useful to make them public. Please comment. I propose three weeks for discussion. I have also opened a ticket: http://hackage.haskell.org/trac/ghc/ticket/4535 and attached a ptach there with working implementation. It would be useful to run it against some tests. (I am sorry that patch is not in darcs format.) Mitar

5 11