December 2011 - Libraries

Should the PVP be changed with regards to instances?
by Johan Tibell 22 Dec '11

22 Dec '11

Hi, I find myself reluctant to add new instances to the unordered-containers package, because doing so would require a major version bump according to the PVP. Major version bumps are annoying for several reasons: * Libraries that depend on unordered-containers need to be updated and make new releases. * We get rapid successions of major releases without many actual changes (i.e. none as far as most users are concerned). Introducing new instances is unlikely to break users, as they will only get into trouble if they use orphan instances, which is already asking for trouble! Thoughts? Cheers, Johan

13 18

Re: [Haskell-cafe] Alternative versus Monoid
by Bas van Dijk 21 Dec '11

21 Dec '11

On 16 December 2011 16:26, Yves Parès <limestrael(a)gmail.com> wrote: > "1) What about the First type? Do we {-# DEPRECATE #-} it?" > > Personnaly, I'm in favor of following the same logic than Int: > Int itself is not a monoid. You have to be specific: it's either Sum or > Mult. > > It should be the same for Maybe: we remove its instance of Monoid, and we > only use First and Last. The reason you need to be specific with Int is that it's not clear which semantics (sum or product) you want. The semantics of Maybe are clear: it's failure-and-prioritized-choice. Changing the order of the arguments of mappend should be the job of Dual. If we really want to drop the Monoid instance for Maybe and keep First and Last and also want to be consistent we should also drop the Monoid instances of [a], a->b, Endo a and of all the tuples. And instead define Monoid instance for First [a], Last [a], First (a->b), Last (a->b), etc. I don't think this is what we want. Regards, Bas

4 4

Re: Should the PVP be changed with regards to instances?
by John Lato 21 Dec '11

21 Dec '11

> From: Johan Tibell <johan.tibell(a)gmail.com> > > Hi, > > I find myself reluctant to add new instances to the unordered-containers > package, because doing so would require a major version bump according to > the PVP. Major version bumps are annoying for several reasons: > > * Libraries that depend on unordered-containers need to be updated and > make new releases. > * We get rapid successions of major releases without many actual changes > (i.e. none as far as most users are concerned). > > Introducing new instances is unlikely to break users, as they will only get > into trouble if they use orphan instances, which is already asking for > trouble! I'm in the same situation, however I'm quite hesitant to add new instances in a minor version. Adding new dependencies can cause breakage even without orphan instances, if downstream packages import a different version of that dependency already. Practically this may be an acceptable short-term solution, but I agree with Ganesh that major version bumps should be made less painful. I've never really liked the PVP anyway as it relies upon a (rather shaky, it now appears) convention. I'd much prefer an automated solution that uses exported/declared interfaces (autoconf is right in principle). I would contribute towards a system like that to replace the PVP and version number-based dependencies as a long-term goal. John L.

2 5

Re: [Haskell-cafe] Alternative versus Monoid
by Bas van Dijk 21 Dec '11

21 Dec '11

On 16 December 2011 05:26, Brent Yorgey <byorgey(a)seas.upenn.edu> wrote: > I, for one, would be > quite in favor of changing the current Monoid (Maybe a) instance to > correspond to the failure-and-prioritized-choice semantics So lets do this. Some questions: 1) What about the First type? Do we {-# DEPRECATE #-} it? 2) What about the Last type? It could be deprecated in favor of Dual. 3) Do we need a new type (like the current Maybe) for lifting semigroups into a Monoid? IMHO we don't since the semigroup package does a better job with the Option type (like Brent mentioned). 4) How much code will break from this change? 5) Anyone up for proposing this to libraries(a)haskell.org? Regards, Bas

2 3

[PATCH] Fix "parallel" package's dependencies to support GHC 7.4
by Herbert Valerio Riedel 19 Dec '11

19 Dec '11

See attached patch against http://darcs.haskell.org/packages/parallel.git/

2 1

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

Use sharing in the Alternative instance of Maybe
by Bas van Dijk 15 Dec '11

15 Dec '11

Hello, When looking at the Alternative instance of Maybe I noticed that the <|> combinator doesn't share it's first argument when it could. So I propose to make the following change: instance Alternative Maybe where empty = Nothing - Nothing <|> p = p - Just x <|> _ = Just x + Nothing <|> r = r + l <|> _ = l Since this isn't a change in the API, I guess this doesn't need to go through the library submission process. http://hackage.haskell.org/trac/ghc/ticket/5699 Cheers, Bas

4 6

Proposal (base): Add new Exp constructor to Text.Read.Lex.Lexeme
by Gracjan Polak 12 Dec '11

12 Dec '11

Core of proposal: Add data Lexeme ... | Exp Integer Integer -- ^ Floating point literal in exponential form a*10^b So that numbers in exponential notation can be represented directly. Rationale: Currently when parsing 12e1000000000000 it is at some point represented as Rational, and of course does not fit in memory. Later on this Rational is converted to Integer or Int8 or Float or Double, but we never get to that point. This uncovers three bugs: 1) 12e12 :: Integer should not parse per Report 2) 12eXXX :: Double should parse, for large values of XXX should give +Infinity, for large negative values of XXX should give +0.0 3) integer-gmp (and/or integer-simple) is not immune to allocation errors and does 'Segmentation violation' or 'Bus error' (sometimes correctly throws 'Out of memory' though) My proposal addresses 1) and 2) as I needed to change public interface of Text.Read.Lex to get it fixed. More info and a patch in trac: http://hackage.haskell.org/trac/ghc/ticket/5688 As reading numbers is core for web (for example HTTP headers, URLs, JSON etc) this is a security issue. As this is security issue I'm tempted to insist this goes into GHC 7.4. What do you think? Discussion period: 2 weeks, 25 Dec 2011. -- Gracjan

4 6

remove a Set of keys from a Map
by Henning Thielemann 10 Dec '11

10 Dec '11

I have (x :: Set key) and (m :: Map key a) and want to remove all keys and corresponding values from m that are in x. I could solve it efficiently with a differenceSet :: Map key a -> Set key -> Map key a or with a Map.fromKeySet :: a -> Set key -> Map key a or a Map.fromKeySet :: (key -> a) -> Set key -> Map key a but I did not find one of these functions in containers-0.4.2.

4 3

Minor containers API changes
by Milan Straka 09 Dec '11

09 Dec '11

Hi everyone, I have several containers API changes propositions. First five are an attempt to unify the API of different structures. The documentation states IntMap is Map replacement and IntSet is Set replacement, but there are several shortcomings: 1) `{Map,Set}.deleteMin empty` return `empty` `{IntMap,IntSet}.deleteMin empty` trigger `error "Cannot delete in empty..."` Solutions: (a) make `{Map,Set}.deleteMin empty` throw error (b) make `{IntMap,IntSet}.deleteMin empty` return empty I vote for (b), because (a) could cause unexpected runtime errors. Additionally, I expect very little programs depend on `{IntMap,IntSet}.deleteMin empty` causing runtime error. 2) `Map.deleteFind{Min,Max}` has type `Map k a -> ((k,a),Map k a)` `IntMap.deleteFind{Min,Max}` has type `IntMap a -> (a, IntMap a)` Solutions: (a) make the Map variant return only values (b) make the IntMap variant return both key and value I vote for (b), because it generalizes the original functionality. 3) `Map.update{Min,Max}` is given a function of type `(a -> Maybe a)` `Map.update{Min,Max}WithKey` is given a function of type `(key -> a -> Maybe a)` `IntMap.update{Min,Max}` is given a function of type `(a -> a)` `IntMap.update{Min,Max}WithKey` is given a function of type `(key -> a -> a)` Solutions: (a) the Map variants would get a function of type `[key -> ] a -> a` (b) the IntMap variants would get a function of type `[key -> ] a -> Maybe a` I vote for (b), because it generalizes the original functionality. 4) The functions `mapKeys :: Ord k2 => (k1->k2) -> Map k1 a -> Map k2 a` `mapKeysWith :: Ord k2 => (a -> a -> a) -> (k1->k2) -> Map k1 a -> Map k2 a` `mapKeysMonotonic :: (k1->k2) -> Map k1 a -> Map k2 a` have no IntMap correspondents. Both `mapKeys` and `mapKeysWith` can be defined by the user without loss of performance. Solutions: (a) deprecate the `mapKeys*` methods from Map (b) add the `mapKeys*` methods to IntMap. I vote for (a). These methods are all trivial compositions and all but all mapKeysMonotonic are defined as such. For mapKeysMonotonic, a trivial composition with the same asymptotic complexity exists. Also, if these were added to IntMap, none of them would have better performance then user-defined methods. 5) `toDescList` exists in Map, but not in IntMap, Set or IntSet. Solutions: (a) deprecate `Map.toDescList` (b) add `toDescList` to IntMap. In this case, we should consider adding it also to Set and IntSet. I have no strong opinion here. The `toDescList` can be trivially expressed as left fold. But it is currently a subject to list fusion. To vote for (a). Several other changes follow: 6) Result of discussion around http://hackage.haskell.org/trac/ghc/ticket/5242 Add `Map.fromSet :: (key -> a) -> Set key -> Map key a` `IntMap.fromSet :: (Int -> a) -> IntSet -> IntMap a` The implementation would exploit same structure of map and set (leave the shape of the original tree/trie, just adding values). Cons: fromSet is a trivial composition: fromSet f = Map.fromDistinctAscList . map (\k -> (k, f k)) . Set.toAscList This can be defined by the user and is asymptotically optimal. Pro: performance. Also the performance of keysSet would improve, if the map can use data constructors of set. I vote for adding these methods. 7) Improve the generality of intersectionWith. Currently the Map and IntMap define intersectionWith :: Ord k => (a -> b -> c) -> Map k a -> Map k b -> Map k c intersectionWithKey :: Ord k => (k -> a -> b -> c) -> Map k a -> Map k b -> Map k c But the combining function is not general enough. Consider two IntMaps storing hashable elements as (hash(element), element). When intersecting elements with the same hash, the intersection can be empty. I propose to change the type of these methods to intersectionWith :: Ord k => (a -> b -> Maybe c) -> Map k a -> Map k b -> Map k c intersectionWithKey :: Ord k => (k -> a -> b -> Maybe c) -> Map k a -> Map k b -> Map k c (and appropriately for IntMap). Note that the combining function of differenceWith already has type `(a -> b -> Maybe a)`. Discussion period: 2 weeks Cheers, Milan PS: Sorry for the long email.

17 40