September 2011 - Libraries

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

27 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 21 Jan '12

21 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

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

11 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

[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

Proposal #3339: Add (+>) as a synonym for mappend
by Bryan O'Sullivan 08 Nov '11

08 Nov '11

Ticket: http://hackage.haskell.org/trac/ghc/ticket/3339 >From the ticket: This proposal was, I think, originally suggested by Jules Bean. The idea is to add two functions to the Data.Monoid module, (+>) and (<+), corresponding to different uses of mappend. These should not be methods of the Monoidtypeclass, but top-level functions. I hope (but slightly doubt) that the visual nature of the two operators might help to counter the thought that monoids are just for gluing things together. (+>) :: (Monoid a) => a -> a -> a a +> b = a `mappend` b (<+) :: (Monoid a) => a -> a -> a a <+ b = b `mappend` a infixl 4 +> infixl 4 <+ Proposed deadline: two weeks. If this looks reasonable, I'll attach darcs patches.

30 75

Proposal: Remove Show and Eq superclasses of Num
by Ian Lynagh 04 Nov '11

04 Nov '11

Hi all, I would like to propose that we remove the Show and Eq superclasses from Num, i.e. change class (Eq a, Show a) => Num a where [...] to class Num a where [...] The first 2 attached patches (for base and ghc respectively) remove the Show constraint. I'm not aware of any justification for why this superclass makes sense. The next 2 patches (for base and unix respectively) remove the Eq constraint. Here's there's some justification in the superclass, as it makes f 5 = ... work for any Num type, rather than also needing an Eq constraint, but personally I would be in favour of removing this superclass too. Noteworthy is that Bits now needs an Eq superclass for the default methods for 'testBit' and 'popCount'. The fifth patch (for base) is what prompted me to get around to sending this proposal. It lets us de-orphan the Show Integer instance. Any opinions? Suggested discussion deadline: 12th October Thanks Ian

21 50

Non-controversial rewrite RULES for time package
by Liyang HU 31 Oct '11

31 Oct '11

Hi, The time package is too slow. :( A prime example is diffUTCTime, which invokes utcTimeToPOSIXSeconds, which in turn calls realToFrac :: DiffTime -> NominalDiffTime. The former of these two types notionally accounts for leap seconds, while the latter does not. Both are newtypes around Data.Fixed.Pico. Since realToFrac is used in the library only when we know the difference is within one day, the two notions coincide, and there is no need to account for leap seconds. Indeed it currently (or rather, its implementation of "fromRational . toRational") behaves as such. I propose we include some rewrite RULES to eliminate the round-trip via Rational. For the attached benchmark, I get a ~4x improvement in speed. Discussion period: 2 weeks. Cheers, /Liyang

3 2

Proposal: Add default instances for Functor and Applicative
by Maciej Marcin Piechotka 23 Oct '11

23 Oct '11

The problem of backward compatibility have been the main obstacle against adopting Functor f => (Pointed f =>?) => Applicative f => Monad f. This proposition is to add following default instances[1]: default fmap :: Applicative f => (a -> b) -> f a -> f b f `fmap` m = pure f <*> m default pure :: Monad f => a -> f a pure = return default (<*>) :: Monad f => f (a -> b) -> f a -> f b (<*>) = liftM2 ($) The proposition is intended as step towards implementing whole hierarchy of Functor f => (Pointed f =>?) => Applicative f => Monad f[2] Discussion period: 2 weeks Regards [1] It's using DefaultSuperclassInstances extentions: http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances [2] Trivial implementation is shown here: http://thread.gmane.org/gmane.comp.lang.haskell.libraries/16196 I believe that in such case the Pointed instance comes at nearly zero cost.

7 11