- Libraries - Haskell.org

getModificationTime and directory-1.2
by Ganesh Sittampalam 13 Sep '12

13 Sep '12

Hi, directory 1.2 switches to being based on 'time' rather than 'old-time'. Because time values are exposed in its external API, this is causing some disruption. In particular something like this pattern seems relatively common: getModTime :: FilePath -> IO EpochTime getModTime path = do (TOD s _) <- getModificationTime path return $! fromIntegral s i.e. get the modification time of a file in seconds since the UNIX epoch. The replacement is something like: t <- getModificationTime path return $! fromInteger $ floor $ t `diffUTCTime` UTCTime (fromGregorian 1970 1 1) 0 But if you want to be backwards compatible then cabal flags and CPP are needed, so it's all a bit verbose. Amongst the dependencies of darcs, I've found myself making a similar change to three packages now (unix-compat, tar, zip-archive), so I wonder if it's worth putting this function somewhere central? One problem is that it's too late to put it in directory, because 1.2.0.0 was shipped with ghc 7.6.1 and so packages need to work against that version. How do people feel about a small package, e.g. 'directory-time' or 'modtime'? Or is there some cleaner workaround that I've missed? Cheers, Ganesh

2 2

Network.firstSuccesful: 'throw' vs 'throwIO' usage
by Herbert Valerio Riedel 06 Sep '12

06 Sep '12

Hello, while reading over the source code of network[1], I noticed a use of 'throw' where I'd expect 'throwIO': import qualified Control.Exception as Exception catchIO :: IO a -> (Exception.IOException -> IO a) -> IO a catchIO = Exception.catch -- Returns the first action from a list which does not throw an exception. -- If all the actions throw exceptions (and the list of actions is not empty), -- the last exception is thrown. firstSuccessful :: [IO a] -> IO a firstSuccessful [] = error "firstSuccessful: empty list" firstSuccessful (p:ps) = catchIO p $ \e -> case ps of [] -> Exception.throw e _ -> firstSuccessful ps ...so, is `throw` used properly in the code above, or should it rather be `throwIO`? [1]: http://hackage.haskell.org/packages/archive/network/2.3.1.0/doc/html/src/Ne…

3 5

Data.Graph
by Evan Laforge 03 Sep '12

03 Sep '12

I just fixed a bug in my program that came about because the same graph constructed in different orders compared inequal. E.g.: buildG (0, 2) [(0, 1), (0, 2)] /= buildG (0, 2) [(0, 2), (0, 1)] It seems to me that these should compare equal. This was easy for me to do since I wrap Graph in a newtype, but it's hard to do for Graph itself, since it's defined as a type synonym over Data.Array. Do people agree that (==) is incorrect for Data.Graph, or is there a legitimate difference between the two graphs? If people agree, what can be done to fix Data.Graph? Should be add Data.Graph2 that is defined as a real type and start anew from there? In general, it seems to me Data.Graph is very basic and has not received any love for a long time. It's a thin wrapper over Data.Array, which is one of the more error-prone ornery APIs out there. To use it I wound up writing lots of little utility functions to do things like add or remove edges which were fiddly and error prone. I just noticed a package graph-wrapper, with the description "A wrapper around the standard Data.Graph with a less awkward interface", so I guess I'm not the only person to have felt that way. Wouldn't it be nice to start taking steps toward having a graph library in the stdlib that people actually like?

7 6

Removing the .Safe modules from vector (was: Haskell Platform proposal: Add the vector package)
by Johan Tibell 01 Sep '12

01 Sep '12

Hi all, After reading the Safe Haskell paper today, I got the impression that no one actually wants the .Safe modules currently in vector. If vector was to be made Safe Haskell friendly, we should instead add .Unsafe modules (and have the rest of the modules declared Trustworthy). Having .Unsafe modules is better than having .Safe modules, because * there are many more safe functions than unsafe functions, and * Haskell is by default safe, so having modules called .Safe is a bit like having modules called .Pure. There's precedence for having .Unsafe modules in e.g. bytestring. If that's the case, and if Roman agrees, I suggest we release a new major version that * removes all the .Safe modules [1], * adds new .Unsafe modules, and * marks the functions that are now exported through the .Unsafe modules deprecated in their original (non-.Unsafe) location. I suggest that the deprecation doesn't involve an actual deprecation pragma in this release [2], but instead just a comment. A future major release could add the deprecation pragma and another major release after that could remove the actual functions. Actually removing functions causes huge Hackage churn so I suggest that we don't do that until the new .Unsafe modules have been around for a long time. 1. Normally I would suggest a deprecation period before removing functions from an API, but I just searched through all of Hackage and there's only a single package (bitvec) that makes use of the .Safe API 2. While deprecation pragmas sound good in theory there isn't much library authors can do to make the warning go away. An author can migrate to the new API, but in practice authors need to support a couple of releases of each library. Cheers, Johan

11 14

HP 2012.4.0.0 -- Call for Proposals
by Mark Lentczner 29 Aug '12

29 Aug '12

While proposals for changes to Haskell Platform can be made at any time, this call is for proposals that would like to land in the 2012.4.0.0 release. The 2012.4.0.0 is scheduled for November 12th, 2012. In order for a proposal to made it in that release, it needs to meet the following timeline: - *August 20th, 2012* - Call for proposals for additions and changes - *September 17th, 2012* - Call for proposals ends (no more proposals considered) - *October 1st, 2012* - Proposals decided, Initial version list *If you are a maintainer of a library that you'd like to be in the platform: * Now is the time to get a clean version on Hackage, and then put together a proposal for the haskell-platform list. Please see the process for Adding Packages <http://trac.haskell.org/haskell-platform/wiki/AddingPackages>. *Outstanding work:* - There is a proposal to include vector-0.9.1 in the platform - There is a ticket to consider including OpenGLRaw — Ticket #167<http://trac.haskell.org/haskell-platform/ticket/167> - There are tickets to consider removing OpenGL and GLUT — Ticket #57<http://trac.haskell.org/haskell-platform/ticket/57>, Ticket #58 <http://trac.haskell.org/haskell-platform/ticket/58> - There is a ticket about binary being in the platform without being part of it — Ticket #191<http://trac.haskell.org/haskell-platform/ticket/191> - There is a ticket about needing hscolour to build the platform, but it isn't part of it — Ticket #160<http://trac.haskell.org/haskell-platform/ticket/160> Please not that none of the tickets is a proposal before the list yet. If the maintainer of those libraries, or someone else, want to propose a change based on those tickets, now is the time to do so. In any event, I will close those tickets on September 17th. *If you are part of the reviewing process:* Traditionally, proposals have been accompanied by lengthly discussions, often resulting in deep API design confabs. As we are approaching a release, I'd like to ask all to consider making this round more succinct if at all possible. In particular, it would be great if proposals were keyed to specific revisions of a library to be considered. If consensus is that something needs to be changed before inclusion - it would be best if maintainers took that input into account, turned another library version and placed that up for consideration. Please note the schedule: I'm going to hold October 1st firm. — Mark "proposed in a restaurant in front of friends" Lentczner

15 24

Proposal: unsnoc, unsafeInit and unsafeLast for the bytestring library
by Mikhail Vorozhtsov 29 Aug '12

29 Aug '12

Hi. I propose to add the missing counterparts of `uncons` and `unsafeHead/Tail` functions to the bytestring library. Discussion deadline: 2 weeks The patch is attached.

5 10

Signature of Control.Monad when and unless
by Oren Ben-Kiki 26 Aug '12

26 Aug '12

I understand why the normal signature is: when :: Monad m => Bool -> m () -> m () unless :: Monad m => Bool -> m () -> m () But why isn't there also: when_ :: Monad m => Bool -> m a -> m () unless_ :: Monad m => Bool -> m a -> m () That is, I agree that results shouldn't be discarded "by default", but it should be easy to get rid of them if they are unneeded. Thanks, Oren Ben-Kiki

6 5

Add binary and/or cereal to the Haskell Platform
by Yitzchak Gale 23 Aug '12

23 Aug '12

I see that several years ago a proposal page was prepared for adding the binary package to the Haskell Platform, but it was never actually submitted as a proposal. http://trac.haskell.org/haskell-platform/wiki/Proposals/binary I think the reason it was not submitted was that things were in flux at that time regarding the binary and cereal packages. Now the situation has settled down. I think one or both of those packages ought to be added to the platform. Any opinions? Thanks, Yitz

5 8

addForeignPtrFinalizer - finalizers run in FIFO or LIFO order?
by Henning Thielemann 19 Aug '12

19 Aug '12

The doc of base-4.5:Foreign.ForeignPtr.addForeignPtrFinalizer states: "This function adds a finalizer to the given foreign object. The finalizer will run before all other finalizers for the same object which have already been registered." I do addForeignPtrFinalizer finalize1 fp addForeignPtrFinalizer finalize2 fp and let the finalizers print something when they are started. I get the output: finalizer1 finalizer2 This indicates that the newly added finalizer is run _after_ the finalizers that are already registered. Is this a documentation bug or a bug in the base library?

3 6

maybeRead in base
by Tom Murphy 17 Aug '12

17 Aug '12

It would be great to have maybeRead in base in time for the next Haskell Platform release. There's been talk about including it several times, but it's remained as a utility function in other libraries (Network.CGI, for example, if I'm remembering right). Tom

5 5