- Libraries - Haskell.org

Data.Ratio and exceptions
by Kazu Yamamoto 16 Jun '12

16 Jun '12

Hello, Some functions in Data.Ratio call the error function. The following is an example: recip (0:%_) = error "Ratio.%: zero denominator" We cannot catch this error as ArithException since it is ErrorCall. Are there any reasons to not use ArithException? --Kazu

8 14

Haskell platform proposal: the async package
by Simon Marlow 15 Jun '12

15 Jun '12

I am making a formal proposal to have the async package included in the Haskell Platform: http://trac.haskell.org/haskell-platform/wiki/Proposals/async See the wiki paage for details, and a list of open issues for discussion. I just uploaded the async package itself to Hackage: http://hackage.haskell.org/package/async-2.0.0.0 documentation isn't there yet, so I've uploaded it here: http://community.haskell.org/~simonmar/async/ I have set the deadline to 13 August 2012 (2 months' time), with comments due by 13 July 2012 (one month). There's plenty of time before the next platform release anyway (scheduled for 12 November 2012). Cheers, Simon

9 10

Re: Proposal: Control.Concurrent.Async
by Sjoerd Visscher 15 Jun '12

15 Jun '12

On Thu, 14 Jun 2012 12:42:51 0100, Simon Marlow <marlowsd(a)gmail.com> wrote: On 13/06/2012 22:58, Sjoerd Visscher wrote: > > (page1, page2, page3) > > <- runConcurrently $ (,,) > > <$> Concurrently (getURL "url1") > > <*> Concurrently (getURL "url2") > > <*> Concurrently (getURL "url3") > > > > More code here: https://gist.github.com/2926572 > > I'm not sure about this. What you get with the above code is a > strange nesting of concurrently calls, whereas what the user might > expect is for it to behave like the existing concurrently but on > 3-tuples instead of pairs. Actually, that is what I expected too. So, this is not the way to use concurrently? concurrently3 m1 m2 m3 = (((v1, v2), v3) -> (v1, v2, v3)) <$> concurrently (concurrently m1 m2) m3 Would this be the correct implementation then: concurrently3 m1 m2 m3 = withAsync m1 $ \a1 -> withAsync m2 $ \a2 -> withAsync m3 $ \a3 -> wait3 a1 a2 a3 And can I then write wait3 as wait3 a1 a2 a3 = (((v1, v2), v3) -> (v1, v2, v3)) <$> do withAsync (waitBoth a1 a2) $ \a12 -> waitBoth a12 a3 or does it have to be: wait3 a1 a2 a3 = atomically $ do v1 <- waitSTM a1 `orElse` (waitSTM a2 >> waitSTM a3 >> retry) v2 <- waitSTM a2 `orElse` (waitSTM a3 >> retry) v3 <- waitSTM a3 return (v1, v2, v3) If it is this complicated, then (properly written) Applicative and Alternative instances are certainly useful. > I like the idea of generalising to arbitrary Traversable structures > though. Maybe we could provide something like > > doConcurrently :: Traversable t => t (IO a) -> IO (t a) > > I haven't tried to write it, but it looks like it ought to be possible. You'll need an Applicative instance for this anyway. -- Sjoerd Visscher https://github.com/sjoerdvisscher/blog

3 2

Data.Tuple impoverished
by Andreas Abel 15 Jun '12

15 Jun '12

Hi, the module Data.Tuple offers a sad collection of 5 functions. Many standard functions are missing. For instance, I'd expect all the functions of Data.Tuple.HT (package utility-th) to be part of Data.Tuple, which are mapPair :: (a -> c, b -> d) -> (a, b) -> (c, d) mapFst :: (a -> c) -> (a, b) -> (c, b) mapSnd :: (b -> c) -> (a, b) -> (a, c) -- swap :: (a, b) -> (b, a) -- swap is present in Data.Tuple forcePair :: (a, b) -> (a, b) fst3 :: (a, b, c) -> a snd3 :: (a, b, c) -> b thd3 :: (a, b, c) -> c curry3 :: ((a, b, c) -> d) -> a -> b -> c -> d uncurry3 :: (a -> b -> c -> d) -> (a, b, c) -> d Is there a good reason why they aren't? Cheers, Andreas P.S.: I have reimplemented all these functions for myself, because I use them, but I am puzzled why they are not in the standard library. -- Andreas Abel <>< Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.abel(a)ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/

7 7

Re: Proposal: Control.Concurrent.Async
by Sjoerd Visscher 15 Jun '12

15 Jun '12

> > An alternative, equivalent interface for waitEither and friends would be > > > > waitEither :: Async a -> Async a -> IO (Either SomeException a) > > waitEitherThrow :: Async a -> Async a -> IO a > > > > This might be conceptually simpler, leaving it to the user to decide > > whether to mark the results with Left/Right, or something else, or not. > > Similarly the Async now returned by waitAny and friends could be left > > to the user. That would leave the two sets of functions more in line. > > I liked this suggestion at first, but later concluded that it isn't > as nice. The problem is that to convert an 'Async a' to an 'Async > (Either a b)' has to be done when you create the Async in the first > place, or else you have to write some STM code to lift the result. > If you're writing some STM code anyway, then there's little point in > using waitEither. What's the problem with converting when you create the Async? > withAsync (Left <$> getUrl url1) $ a1 -> do > withAsync (Right <$> getUrl url2) $ a2 -> do > waitEither a1 a2 This seems more explicit to me. And if you really don't care which of the results you want, they'll probably have the same type anyway. Greetings, Sjoerd

2 1

Moving hashable to HP/base (Was: Proposal: Remove Data.HashTable from base)
by Johan Tibell 14 Jun '12

14 Jun '12

On Thu, Jun 14, 2012 at 6:01 PM, Bryan O'Sullivan <bos(a)serpentine.com> wrote: > I'd be in favour of that. This would also make it possible to either add > unordered-containers to the platform, or (preferably) merge > unordered-containers into containers. I want to do the latter. Now when the implementation of unordered-containers is stable it makes sense to integration it into containers and expand the API. I think Hashable might have to go into base. It's hard to have core type classes outside of base due to orphan instance problems. -- Johan

1 0

Re: Proposal: Control.Concurrent.Async
by Sjoerd Visscher 14 Jun '12

14 Jun '12

And perhaps an Alternative instance would also be useful: instance Alternative Concurrently where empty = Concurrently $ forever (threadDelay maxBound) Concurrently as <|> Concurrently bs = Concurrently $ either id id <$> race as bs Where "empty" should be the cheapest way to loop forever, I don't know if this is the best way to do that. Sjoerd On Wed, 13 Jun 2012 23:58:54 +0200, Sjoerd Visscher <sjoerd(a)w3future.com> wrote: Hi Simon, > > This a really nice and clean library! > > I was wondering if it would be useful to have an applicative > interface for the concurrently function? Something like this: > > (page1, page2, page3) <- runConcurrently $ (,,) <$> > Concurrently (getURL "url1") <*> Concurrently (getURL "url2") > <*> Concurrently (getURL "url3") > > More code here: https://gist.github.com/2926572 > > Thanks, > Sjoerd > > On Jun 8, 2012, at 10:37 AM, Simon Marlow wrote: > > > I'd like to add a higher-level concurrency API to the base package. > This API has grown while I've been working on examples for my book, > and I'm convinced that we should have something like this in the > standard libraries. Here's the API I propose: > > > > http://community.haskell.org/~simonmar/async-stm/Control-Concurrent-Async.h… > > > In fact it already exists in at least two packages on Hackage: > 'async' and 'threads'. My version is a superset of both of these, > except for a few small differences (which are up for discussion, of > course). > > > One good reason to have this package is that it avoids some > common pitfalls, such as forgetting to handle exceptions in your > child threads. In the Async API, you get to choose whether to (a) > receive the result as 'Either SomeException a', or (b) have the > exception re-thrown in the waiting thread. You don't get to ignore > it altogether. > > > Another common pitfall avoided by this library is accidentally > leaving threads running in the background. This is handled by > withAsync: > > > withAsync :: IO a -> (Async a -> IO b) -> IO b > > > the child thread is always cancelled (i.e. killed) when the > second argument returns or throws an exception, if it hasn't finished > already. > > > > I'm opening this up for discussion so that we can tidy up any > inconsistent details and add any functions that people feel are > missing. Naming is obviously up for discussion too. > > > Cheers, > > Simon > > > > > _______________________________________________ > > Libraries mailing list > > Libraries(a)haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > -- > Sjoerd Visscher > https://github.com/sjoerdvisscher/blog > > > > > > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -- Sjoerd Visscher http://w3future.com/

1 0

Audio Book On India
by cs an 14 Jun '12

14 Jun '12

Sir/Madame Iam senior Civil Service Officer(IRS) from India, retired recently. I was working as Commissioner of Income Tax. I am approaching you in cnnection with an audio book, I have devloped on India which covers various aspects of the country such as populaion, Geography, History,Polity,Economy, National Movement, great personalities, environmental issues etc. It is 30 hrs fairly high quality recording with 500 audio articles.Audio book comes in preloaded MP3 player. I have web site which contains all details including sample audios. please visit www.civilservicesaudionotes.com. I will be happy to supply copy/s to your library. Thanking You Yours Sincerely Prakash H Adnur ____________________________________________________________________________________________________________________ Prakash H Adnur IRS ( Retd ) ADNUR EDUCATION FOUNDATION #7, 1St “A” Main, 2nd ‘A’ Cross Dollars Colony, Ashwath Nagar, RMV 2ndStage, BANGALORE - 560094. Ph : 9980718114 Email:*civilservicesaudionotes@gmail.com**.*<http://civilservicesaudionotes@gmail.com.>

1 0

Proposal: better timestamp granularity for modificationTime/setFileTimes in System.Posix.Files[.ByteString]
by Marios Titas 13 Jun '12

13 Jun '12

Dear all, System.Posix.Files[.ByteString] contains the following functions related to file times: accessTime, modificationTime, statusChangeTime, setFileTimes. All of these functions offer granularity of one second. Modern posix systems support newer functions (such as utimes, utimensat) that offer better granularity (up to 1 nanosecond). I propose to add a new set of functions to System.Posix.Files[.ByteString] to utilize these new capabilities. One problem here is the choice of the data type to be used for these timestamps as the EpochTime type only allows granularity of one second. One option might be POSIXTime from Data.Time.Clock.POSIX. I am willing to provide patches.

2 3

Re: [Haskell] Types of when and unless in Control.Monad
by Andreas Abel 06 Jun '12

06 Jun '12

On 06/04/2012 08:47 PM, Christian Höner zu Siederdissen wrote: > Hi Andreas, > > I think you missed our point. Say: > > gearDown :: IO Bool > landPlane :: IO () > > do > g<- gearDown > if g > then landPlane > else error "we're all gonna die, bail out" > > But now, I am really lazy (in a bad way) > > do > when gearDown > landPlane You probably meant to write do gearDown landPlane (Since 'when' expects a pure Bool, the code you wrote does not type-check.) Well, you can ignore results in a 'do', but this has nothing to do with 'when'. There is a ghc flag -fwarn-unused-do-bind that prevents you from ignoring results silently, in this case you would have to write do _ <- gearDown landPlane to make it obvious that you ignore a result of a monadic computation. Maybe you prefer this style, but I would like the freedom to silently ignore unneeded results. > I can not now accidentally land my plane if my gear ist stuck in "up" > (returned false). If "when" suppresses the return value, the compiler > does not warn you if you use "when" together with a function that > returns something important. It seems you have confused condition- and then-part of 'when'. > My point is /not/ that I want the result of "when", but that I want to > know that I am currently suppressing the result of the inner action, > which could be disastrous. > > And simply adding "when_" is the safest (one of the safer?) way of > dealing with your wish. The reason to have a mapM_ additionally to mapM is that in some cases, e.g. as last statement of a do block of type m (), mapM does not type check. However, generalizing the type of 'when' does not break any programs, and then a when_ is superfluous. More in an answer to Henning... Cheers, Andreas > * Andreas Abel<andreas.abel(a)ifi.lmu.de> [04.06.2012 20:36]: >> On 04/22/2012 01:49 PM, Ivan Lazar Miljenovic wrote: >>> On 22 April 2012 21:39, Christian Höner zu Siederdissen >>> <choener(a)tbi.univie.ac.at> wrote: >>>> * Julian Gilbey<julian(a)d-and-j.net> [22.04.2012 09:22]: >>>>> On Sat, Apr 21, 2012 at 08:28:27PM -0500, Strake wrote: >>>>>> On 21/04/2012, Andreas Abel<andreas.abel(a)ifi.lmu.de> wrote: >>>>>>> to avoid silly "return ()" statements like in >>>>>>> >>>>>>> when cond $ do >>>>>>> monadicComputationWhoseResultIWantToDiscard >>>>>>> return () >>>>>> >>>>>> (when cond ∘ void) monadicComputationWhoseResultIWantToDiscard >>>>>> or >>>>>> when cond $ ()<$ monadicComputationWhoseResultIWantToDiscard >>>>> >>>>> How is that simpler than >>>>> >>>>> when cond monadicComputationWhoseResultIWantToDiscard >>>>> >>>>> which it would be with the suggested new type? >>>>> >>>>> Julian >>>> >>>> Wouldn't "when_" and "unless_" or similar be better? I'd probably like >>>> to have the compiler annoy me, since it is not clear that I want to >>>> discard the result. If I really want to discard, I should have to make >>>> it clear as there is probably a good reason for the inner function to >>>> return a result in the first place? >>> >>> Agreed; I'm not sure if I agree with having such functionality >>> (Henning makes some good points), but if people deem it desirable then >>> I think it would be better to have them with new names for the reasons >>> you state. >> >> Mmh, this discussion has cooled down, but I just found your answers >> which had been stashed away by my mail agent, and I feel I have to >> reply... >> >> Concerning the suggestion that when_ would be in sync with forM_ and >> whenM_ I'd say: not really. forM_ and whenM_ discard the result of >> the monadic computation, while when and when_ do not even have such >> a result. They always just perform some monadic effect and return >> nothing. >> >> Repeating myself, 'when' can never have a result, since it is an >> if-then without an else. Thus, it is a proper command; and if you >> want to have a conditional monadic computation which does return a >> result, you can simply not use 'when' or 'unless', logic forces you >> to use 'if' or 'ifM'. >> >> I do not understand the worries that one could accidentially use >> 'when' with a monadic computation whose result one actually cares >> for. If that was the intention of the library designers, they >> should have given many other function a more specific type, most >> prominently >> >> >> :: m () -> m b -> b >> >> That would have ensured that you cannot discard the result of the >> first computation by accident. But would you want to work with >> this? My answer is no. >> >> Other types that would be changed to implement this kind of safety >> policy are: >> >> mapM_ :: (a -> m ()) -> [a] -> m () >> forM_ :: [a] -> (a -> m ()) -> m () >> sequence_ :: [m ()] -> m () >> forever :: m () -> m () >> >> and many more, like zipWithM_, foldM_, replicateM_. >> >> Sorry, but I think all these function have been given their maximal >> general type >> >> ==> to be able to ignore a result of a monadic computation >> >> ==> without further noise. >> >> In my opinion, the types of when and unless are not general enough, >> an that is, imho, just an accident of history. Because it is the >> type that inferred for the shortest definition, which is >> >> when cond m = if cond then m else return () >> >> Please reevaluate my proposal to change to >> >> when :: Bool -> m a -> m () >> unless :: Bool -> m a -> m () >> >> in the light of the above arguments. >> >> Cheers, >> Andreas >> >> -- >> Andreas Abel<>< Du bist der geliebte Mensch. >> >> Theoretical Computer Science, University of Munich >> Oettingenstr. 67, D-80538 Munich, GERMANY >> >> andreas.abel(a)ifi.lmu.de >> http://www2.tcs.ifi.lmu.de/~abel/ -- Andreas Abel <>< Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.abel(a)ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/

5 10