June 2012 - Libraries

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

Unboxed Vectors of newtype'd values
by Ben Gamari 06 Jun '12

06 Jun '12

One of the reasons I find Haskell so well suited to my work is its ability to easily work with large quantities of data. In particular, I find myself using Data.Vector.Unbox quite frequently. Another of my reasons for using Haskell is the type safety it provides. I find myself using newtypes very frequently to force myself to think about invariants that a more weakly typed language would allow me to simply ignore. Sadly, these two features don't interact particularly well. While the Data.Vector.Unbox documentation claims that "Implementing unboxed vectors for new data types can be very easy", it then goes on to list an abridged version of the Complex instance---dozens of lines of code. While this code certainly isn't difficult to write, it is time consuming, error-prone, and, above else, utterly mind deadeningly dull (making it quite uncharacteristic for Haskell). So dull that I generally avoid newtypes at all cost in code that might need to use unboxed vectors. This boilerplate is largely due to Vector's use of type families as this precludes the use of (the otherwise quite cunning) GeneralizedNewtypeDeriving to automatically derive the necessary instances. What can be done to fix this unfortunate state of affairs? The obvious solution here seems to be Template Haskell, but this seems a bit of an unfortunate hack around what might be a deficiency in the type families mechanism (or at least this application of it). The newtype package provides a nice mechanism to pack and unpack newtypes, but providing blanket Unbox instances for Newtype instances seems like an awful idea (and, frankly, I'm not sure how this would work with type families). Other than these two possibilities I am at a loss. Thoughts? I'd appreciate any ideas folks could offer. Cheers, - Ben

10 26

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

06 Jun '12

On Jun 06, 2012, at 08:44 AM, Andreas Abel <andreas.abel(a)ifi.lmu.de> wrote: > Well, but nothing in the type system prevents you from writing > > mapM f xs >> cont > > or > > do mapM f xs > cont > > so you are not warned of a space leak in the common situations anyway, At least the second form will trigger a warning in GHC (although admittedly not from the type system, but from -fwarn-unused-do-bind). It is a jolly useful warning at times. Regards, Malcolm

1 0

[ANNOUNCE] cereal-0.3.5.2
by Trevor Elliott 05 Jun '12

05 Jun '12

Hi Everyone, I'm happy to announce version 0.3.5.2[1] of the cereal serialization library. This is a bugfix release, mostly improving performance characteristics of the library. One noteable change is with runGetLazy, which will now perform as expected when a parser attempts to consume more input than is available. Happy hacking! --trevor [1] http://hackage.haskell.org/package/cereal-0.3.5.2

1 0

Re: [Haskell] Types of when and unless in Control.Monad
by Ivan Lazar Miljenovic 05 Jun '12

05 Jun '12

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. -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

4 7

The 'encoding' package maintainer?
by Boris Kropivnitsky 05 Jun '12

05 Jun '12

Hello, I am looking for the maintainer of the 'encoding' library. I tried to use it for my little project, but it turned out that it has some issues and needs some love. So I've made a few fixes and it now works reasonably well. I thought the community will benefit if the new version is made available. I've tried to contact the author listed in the .cabal file but had no luck. So I thought I'd ask for help here. Cheers, Boris Kropivnitsky

2 2

Announce: Haskell Platform 2012.2.0.0
by Mark Lentczner 03 Jun '12

03 Jun '12

We're pleased to announce the next release of Haskell Platform: a single, standard Haskell distribution for everyone. Download Haskell Platform 2012.2.0.0: http://haskell.org/platform/ The specification, along with installers (including Windows, Macintosh, and Unix installers for a full Haskell environment) are available. Notable version changes with this release: ghc 7.4.1 cabal 1.14 & cabal-install 0.14 mtl 2.1.1 & transformers 0.3.0.0 alex 3.0.1 full package and version list: http://hackage.haskell.org/platform/changelog.html Thanks to: Joachim Breitner, George Colpitts, Duncan Coutts, Jason Dagit, Chris Dornan, Yitzchak Gale, Mikhail Glushenkov, Andres Löh, Gábor Páli, Jens Petersen, Don Stewart, David Terei, Johan Tibell, & Mark Wright for their efforts and help in putting together this release. -- The Platform Infrastructure Team Mark Lentczner, release manager --------------------------------------------------------------------- The Haskell Platform is a single, standard Haskell distribution for every system, in the form of a blessed library and tool suite for Haskell distilled from the thousands of libraries on Hackage, along with installers for a wide variety of systems. It saves developers work picking and choosing the best Haskell libraries and tools to use for a task. When you install the Haskell Platform, you get the latest stable compiler, an expanded set of core libraries, additional development tools, and cabal-install – so you can download anything else you need from Hackage.

4 4

SafeSemapore
by Chris Kuklewicz 02 Jun '12

02 Jun '12

This message is in three parts: a problem, a solution, and a request for help. The problem is that Control.Concurrent.QSem, QSemN, and SampleVar are all still broken. GHC ticket #3160 is still open [1]. These three synchronization mechanisms can be irretrievable broken by a killThread on a blocked waiter. The solution is that I am please to announce that SafeSemaphore has been updated to 0.9.0 on hackage [2] and github. These provides safe solutions to replace QSem and QSemN, actually several such solutions. See the github [2] page (scroll down for README) for a summary of all the modules. The request for help is that I would like to unbreak the Haskell Platform by replacing the guts of QSem, QSemN, and SampleVar with SafeSemaphore. Do you think my replacement is correct or buggy? Can we get #3160 closed? Replacing these will preserve their API but may tinker with corner case undocumented behavior. Should waiters block in FIFO order? Should QSemN starve big or small requests to be fairer? [1] http://hackage.haskell.org/trac/ghc/ticket/3160 (three years old!) [2] http://hackage.haskell.org/package/SafeSemaphore/ [3] https://github.com/ChrisKuklewicz/SafeSemaphore Sincerely, Chris Kuklewicz

2 1