October 2011 - Libraries

Proposal: Use time rather than old-time in directory
by Ian Lynagh 17 Sep '14

17 Sep '14

Hi all, This proposal is to change directory to use the time package rather than the old-time package. This will hopefully be a significant step towards actually making the transition in general. I'm not sure if POSIXTime or UTCTime is the better type to use. Does anyone know? I started off with UTCTime, then switched to POSIXTime as UTCTime didn't have a Show instance. I've since found that actually UTCTime has both Show and Read instances, but they are orphaned. So actually, if UTCTime is the better type then switching back to UTCTime would allow us to fix this comment in hpc: -- We would rather use ClockTime in Mix, but ClockTime has no Read instance and simplify the code slightly. Attached are patches for directory, hpc and ghc. Suggested discussion period: Until 5th Nov 2011. Thanks Ian

14 35

Proposal: Add newUniqueSTM to Data.Unique
by Edward Kmett 28 Apr '12

28 Apr '12

Data.Unique's newUnique uses atomically internally to update a TVar. Consequently attempting to "unsafeIOToSTM newUnique" to allocate a Unique within an STM transaction blows you sky high. The proposal is to split the definition of newUnique into: newUnique = atomically newUniqueSTM and expose newUniqueSTM. Alternately, since bug #3838 has been resolved, we could revert to using an IORef, which would avoid the wart of having us have an overtly IO action detonate because of an internal implementation detail of using STM. Since, there are two paths forward, I haven't put forward a patch, but wanted to open a discussion. Discussion Period: 2 weeks. -Edward Kmett

6 12

Proposal: add 'state' to the MonadState class
by Twan van Laarhoven 22 Jan '12

22 Jan '12

Hello list, Currently the 'state' function is only defined for the State type (aka StateT Identity): state :: (s -> (a, s)) -> State s a state f = StateT (Identity . f) But this function makes sense for all MonadState instances. I therefore propose to either add it to the MonadState class: class MonadState s m | m -> s where ... state :: (s -> (a,s)) -> m a state f = do s <- get let (a,s') = f s set s' return a or as a stand alone function like modify. I personally prefer to add it to the class, since that allows for a more efficient implementation. In particular: instance Monad m => MonadState s (StateT s m) where .... state = StateT (return . f) Discussion period: 2 weeks (ends October 10th) Twan

6 10

Proposal to incorporate Haskell.org
by Don Stewart 16 Dec '11

16 Dec '11

Hello everyone. The haskell.org committee[1], in the interest of the long-term stability of the open source Haskell community infrastructure, has decided to incorporate haskell.org as a legal entity. This email outlines our recommendation, and seeks input from the community on this decision. The committee's proposal is that haskell.org incorporate as an entity under the Software Freedom Conservancy umbrella organization (the same group that Darcs joined recently): http://sfconservancy.org/ If we proceed with this move, haskell.org will be a legal entity, and registered as a non-profit, allowing us to more directly accept (US tax-deductible) donations, and to invest in assets that benefit the Haskell open source community. We welcome your feedback on the proposal attached below. -- Don Stewart (on behalf of the Haskell.org committee) ------------------------------------------------------------------------ = A proposal for the incorporation of Haskell.org = In recent years, haskell.org has started to receive assets, e.g. money from Google Summer Of Code, donations for Hackathons, and a Sparc machine for use in GHC development. We have also started spending this money: in particular, on hosting haskell.org itself. There is also interest in running fundraising drives for specific things such as Hackathon sponsorship and hosting fees. However, haskell.org doesn't currently exist as a legal entity, meaning that these assets have had to be held on our behalf by other entities, such as Galois and various universities. This leads to tricky situations, with no-one being sure who should decide how the haskell.org assets can be used. To solve these problems, we propose that haskell.org applies to become a member project of the Software Freedom Conservancy (SFC) <http://conservancy.softwarefreedom.org/>. The SFC is a non-profit organization that provides free financial and administrative services to open source projects. Additionally, it has 501(c)(3) status, meaning donations from the US are tax-deductible. The SFC would hold haskell.org's money and other assets, and would be able to accept donations on behalf of haskell.org. The haskell.org committee, as described here [2], will make decisions on spending assets and other decisions related to governing the non-profit. Before proceeding, we are inviting input from the community in the form of specific objections or queries regarding the plan. We've tried to answer some of the most likely questions: Q: Does this mean that my Haskell project must now be covered by a copyleft licence such as GPL? A: No, but Haskell projects using haskell.org resource should use an Open Source licence <http://www.opensource.org/licenses/alphabetical>. Q: Will it still be possible to use community.h.o to host non-open-source material, such as academic papers? A: An overall minority of such content, as is the current situation, is not a problem. Q: Will it still be possible to have job ads on the haskell.org mailing lists and website? A: Yes. Q: Will this affect our ability to host the Haskell Symposium <http://www.haskell.org/haskell-symposium/> and Industrial Haskell Group<http://industry.haskell.org/> webpages within haskell.org? A: No. Q: What will be the relationship between haskell.org and other organizations such as the Haskell Symposium and Industrial Haskell Group? A: Those organisations will continue to exist as separate entities. Q: If an umbrella non-profit organisation "The Haskell Foundation" was created, would haskell.org be able to join it? A: Yes. It's likely that in such a scenario, the Haskell Foundation would become the owner of the haskell.org domain name, with the cost divided between the members. The entity that is part of the SFC would be renamed "community.haskell.org" in order to avoid confusion. [1]: http://www.haskell.org/haskellwiki/Haskell.org_committee [2]: http://www.haskell.org/haskellwiki/Haskell.org_committee#Operation

4 5

Documentation in Control.Monad.STM.TMVar - isEmptyTMVar
by Heinrich Apfelmus 23 Nov '11

23 Nov '11

Hello, As of stm-2.2.0.1, the documentation for the isEmptyTMVar function [1] reads isEmptyTMVar :: TMVar a -> STM BoolSource Check whether a given TMVar is empty. Notice that the boolean value returned is just a snapshot of the state of the TMVar. By the time you get to react on its result, the TMVar may have been filled (or emptied) - so be extremely careful when using this operation. Use tryTakeTMVar instead if possible. This being software transactional memory, where everything is wrapped into a call to the atomically function, I believe that the second paragraph is now completely obsolete, to the point of being misleading (it sure scared me). I would be relieved if someone could remove it. Most likely, it was originally copied directly from the corresponding documentation of Control.Concurrent.MVar . [1]: http://hackage.haskell.org/packages/archive/stm/2.2.0.1/doc/html/Control-Co… Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

4 4

Proposal: Ignore sub-minor version components in package id
by Joachim Breitner 16 Nov '11

16 Nov '11

Hi, I’d like to propose that the package (shown by "ghc-pkg field <pkg> id" and used by "ghc-pkg field <pkg> depends") should only consist of the first three components of the package version, not all of them. By the package versioning policy, if the API stays the same, these version numbers stay identical. And if the change does not affect the ABI, the hash stays the same. This would allow upgrades of the package without having to re-build everything depending on it. And if the maintainer does not fully follow the PVP, then it is not a big deal either; the hash will change and Cabal will enforce rebuilds. One could argue that the version can be removed entirely from the package id, but it helps the human reader when looking at the "depends" field of a package. Greetings, Joachim -- Joachim "nomeata" Breitner mail(a)joachim-breitner.de | nomeata(a)debian.org | GPG: 0x4743206C xmpp: nomeata(a)joachim-breitner.de | http://www.joachim-breitner.de/

5 10

Proposal: New Eq and Ord instances for Double and Float
by Daniel Fischer 12 Nov '11

12 Nov '11

Proposal: Provide Double and Float with Eq and Ord instances that introduce a total order. Discussion period: Two weeks Rationale: The Eq and Ord instances for Double and Float currently follow the IEEE specification in that * NaN == x = False * NaN /= x = True * NaN < x = False * NaN > x = False * NaN <= x = False * NaN >= x = False This has several undesirable consequences: - (==) does not define an equivalence relation on those types - (<) does not define a total order on those types (not even a partial order) - compare always returns GT if (at least) one argument is a NaN As a result, various algorithms and data structures are broken in the presence of NaNs: Prelude Data.List Data.Set> let nan :: Double; nan = 0/0 Prelude Data.List Data.Set> max nan 1 NaN Prelude Data.List Data.Set> max 1 nan 1.0 Prelude Data.List Data.Set> minimum [0,1,nan,2,nan,3,4,nan,5,6] 5.0 Prelude Data.List Data.Set> sort [0,1,nan,2,nan,3,4,nan,5,6] [0.0,1.0,3.0,5.0,6.0,NaN,4.0,NaN,2.0,NaN] Prelude Data.List Data.Set> let st = fromList [0,1,nan,2,nan,3,4,nan,5,6] Prelude Data.List Data.Set> Prelude.filter (`member` st) [0 .. 10] [0.0,1.0,2.0,5.0,6.0] Prelude Data.List Data.Set> Prelude.filter (`member` (Data.Set.filter (not . isNaN) st)) [0 .. 10] [0.0,1.0,2.0,3.0,4.0,5.0,6.0] ===================== I therefore propose to change the Eq and Ord instances for Double and Float to conform with the behaviour expected from such instances in Haskell, and to make the comparisons with IEEE semantics available from the RealFloat class. In more detail: * Eq: The Eq instance for Double and Float shall be changed so that NaN == NaN = True NaN /= NaN = False Since there are many bit patterns which are NaN values, there remains the question whether all NaNs shall be considered equal or whether only NaNs with identical bit patterns should be considered equal. I lean towards treating all NaNs equal to each other. A different edge-case is negative zero. At the moment, we have 0.0 == (-0.0) = True as mandated by IEEE. The question is whether that should be kept or we want to disinguish between 0.0 and -0.0. Because of recip 0.0 = Infinity recip (-0.0) = -Infinity I lean towards distinguishing. * Ord: The Ord instance shall be modified so that - if currently x < y holds, that shall remain so - NaN shall (arbitrarily, in analogy to Maybe's Ord instance[s]) be considered smaller than all non-NaN values. If Eq should distinguish different NaNs, the Ord instance should do the same. If Eq should distinguish 0.0 and -0.0, so should the Ord instance. * IEEE comparisons: These shall be made available from the RealFloat class (where applicable, if the hardware doesn't provide them, default them to the Ord methods). Two reasons: first their semantics might be needed in some programmes; second, as hardware operations, they're fast, in number-crunching programmes where NaNs can't occur, that can make a significant difference. These operators should be visually similar to the Eq and Ord operators but not too similar. The ML languages - afaik - mark operators on floating point values by appending a dot, (+.), (<.) etc. That seems too easy to overlook to me, by enclosing the operator in dots, (.==.), (.<.) the opportunity to spot the difference is doubled without being too heavy notation. On the other hand, we already use the dot for other things, so using dots as the distinguishing means may be less that optimal. Suggestions welcome.

17 28

Testing containers outside of ghc source tree
by Gracjan Polak 10 Nov '11

10 Nov '11

Hi all, Recent developments in containers made me to give it a spin, too. I'd like to compile and test containers package. I got the sources, compiled. So far so good. Then the testsuite inside source code seems to require GHC testing framework. This seems a bit heavy. Anyway I got recent GHC sources, placed containers under libraries/containers-ex. Running 'make TEST_HC=ghc' in tests directory fails with: *** unexpected failure for sequence001(threaded1) =====> sequence001(threaded2) 4 of 4 [0, 30, 0] cd . && '/usr/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -fno-ghci-history -o sequence001 sequence001.hs -O -threaded -eventlog -package containers >sequence001.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc: unrecognised flags: -fno-ghci-history Usage: For basic information, try the `--help' option. What I aim for is to have a fast/short way of doing some experimental changes and running only the containers testsuite with my own changes included. How do I get to doing this? -- Gracjan

5 5

Proposal: Stop enforcing single-writer-multi-reader file access
by Ian Lynagh 10 Nov '11

10 Nov '11

Hi all, Haskell currently requires that multiple-reader single-writer locking is used on files. I understand the motivation for this was to try to protect people from running into problems due to lazy IO, but in practice I think it just causes more problems than it solves. The decision may also have been influenced by the belief that this behaviour is enforced for all programs on Windows, but I am told that it is possible to get lock-free behaviour on Windows too. I propose that we remove all the automatic locking from the libraries, and let the user do any locking that they wish to do themselves. Attached are patches for ghc, base, process and unix. (not yet tested on Windows). Suggested discussion period: Until 9 Nov 2011 Related GHC ticket: http://hackage.haskell.org/trac/ghc/ticket/4363 Thanks Ian

16 29

[PATCH] haskell-src build fix for ghc-7.2.1
by Conrad Parker 09 Nov '11

09 Nov '11

Hi, the attached patch for haskell-src conditionally depends on haskell98 only for ghc < 7.2.1. A similar patch was sent to libraries@ by Adam Sampson on Aug 14, removing the haskell98 dependency entirely as "Recent versions of Happy don't require it any more", which may be better. (There has been no response to Adam's mail, perhaps listing libraries@ as maintainer is not so useful). Conrad.

2 3