May 2011 - Libraries - Haskell.org

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 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 #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

There are too many error handling conventions used in library code!
by dons＠cse.unsw.edu.au 13 Aug '11

13 Aug '11

This article on the 8 different error handling strategies various common Haskell libs use: http://www.randomhacks.net/articles/2007/03/10/haskell-8-ways-to-report-err… got me thinking: we need to standardise/recommend a small set of methods for library error handling. The lack of consistent error reporting between libs results in verbose code, as we're not able to use a single error handling technique when gluing together code from different libs (i.e. we can't just use Maybe or Either/ErrorT). (It's always nice when you *can* use, say, a Maybe monad to glue code from a number of sources, but eventually you reach code with a different error system, and the Maybe monad breaks down). So, some questions I think we can tackle: * can we identify error handling strategies from the list that should not be used anymore? (throwDyn?) * can we move some of the outlying libraries to a more consistent error framework? * do we need more support for gluing together our different error systems? (it should be easier to glue code using , say, Maybe/Either). * what role does MonadError play here, as a generic error handler? * can we make precise recommendations about which error strategies to use? -- Don

11 16

Re: Proposal: Value strict versions of containers
by Johan Tibell 31 Jul '11

31 Jul '11

Forgot to add libraries@ On Mon, May 23, 2011 at 4:29 PM, Johan Tibell <johan.tibell(a)gmail.com> wrote: > On Mon, May 23, 2011 at 4:18 PM, Sebastian Fischer <fischer(a)nii.ac.jp> wrote: >> Because unboxing can not be used for the polymorphic value component in the >> strict structure and there is no way to tell GHC to unbox the specific >> instantiation `IntMap (Lazy a)`? > > Exactly. This would amount to code generation in the module defining > IntMap (Lazy a), similar to how C++ implements template. > >> I thought GHC would eliminate the indirection and extra words with >> -funbox-strict-fields. > > Unfortunately not. > > Johan >

2 2

Proposal: Make gcd total
by Daniel Fischer 11 Jun '11

11 Jun '11

Reposting to libraries, since I was advised that this would be the correct place, and not haskell-prime, as I assumed because it would change behaviour specified in the language report. The proposal has been made earlier and received widespread support, but it was never finished. This time, on the haskell-prime list, http://www.haskell.org/pipermail/haskell-prime/2011-May/003403.html, Jaques Carette and Cale Gibbard already recorded their support. Discussion period: two weeks, until 11. June 2011. An old and reopened ticket is at: http://hackage.haskell.org/trac/ghc/ticket/3304 The Proposal: I would like to propose the elimination of the special error case gcd 0 0 = error "Prelude.gcd: gcd 0 0 is undefined" to replace it with gcd 0 0 = 0 (which would be an automatic consequence of removing the above line). Rationale: 1. It makes gcd a total function. 2. It makes gcd associative. 3. It makes folding gcd over a list safe. 4. It conforms to common mathematical practice: In a commutative ring, a greatest common divisor of two elements a, b is a common divisor g of a and b such that every common divisor d of a and b also divides g (if R is a commutative ring, a \in R, d \in R is a divisor of a iff there exists c \in R with a = d*c [leaving out noncommutative rings for simplicity]). Since every ring element divides 0, the above definition entails gcd 0 0 = 0. Further, in a principal ideal ring, the greatest common divisors of two elements a and b are the generators of the ideal (a,b), again that characterisation of greatest common divisors says gcd 0 0 = 0: (0,0) = {0} = (0). Pros: see above. Cons: ? I'm not aware of any, the change shouldn't break existing code, since that would have to check for the special case anyway. There is, however, a difficulty with the documentation. Reading the old threads about the topic (thanks to Judah Jacobson for the links): http://www.haskell.org/pipermail/haskell/2001-December/008560.html http://www.haskell.org/pipermail/haskell-cafe/2009-May/060880.html made me aware that many (probably most) people, upon reading 'greatest' in 'greatest common divisor', think it refers to the natural order of integers and not the divisibility preorder. Of course, historically it did, but since the concept has been expanded to rings which have no natural order, it can't anymore (and even in rings which have a natural order, like Z[sqrt 2], the term 'greatest' can't refer to the natural order if the ring has units > 1). It is not difficult to explain this given enough space, but I don't know yet how to fit it in the limited space a reasonable function documentation provides. Suggestions how to formulate it are welcome. Daniel

4 5

RE: Proposal: Make gcd total
by Simon Peyton-Jones 08 Jun '11

08 Jun '11

| > So if someone actually follows through with this as an official | > libraries submission (with a patch, deadline, etc.), the odds seem in | > favor of it. | | I'll try to see it through, although the process seems rather daunting. | It has annoyed me for too long. I think there is general agreement that * The library submission process is too daunting, especially because you have to come up with a complete implementation of a proposal before you even know whether it's going to fly. * The process gets stuck because achieving universal consensus is too difficult * The maintainer "libraries(a)haskell.org" means that no individual feels responsible for making a decision on a proposal. What we need is something to put in its place. Simon and I have been cooking up a proposal. Here it is: http://www.haskell.org/haskellwiki/Library_submissions/NewDraft It is aimed just at libraries whose maintainer is listed as libraries(a)haskell.org. (The thousands of other libraries with named maintainers can obviously do whatever their maintainer wants, although perhaps this new draft may be useful for them too.) It's a draft. What do you think of it? Do you think it would be better than the status quo? Can you suggest any improvements? ALSO: does anyone (or two or three people) want to volunteer to act as maintainer for any of the "Volunteer needed" packages? Johan, I was thinking you might serve for 'containers', perhaps in harness with someone else since it is such a crucial package. Simon

13 24

Re: Proposal: Make gcd total
by Ross Paterson 02 Jun '11

02 Jun '11

On 28 May 2011 11:59, Daniel Fischer wrote: > I would like to propose the elimination of the special error case > > gcd 0 0 = error "Prelude.gcd: gcd 0 0 is undefined" Just deleting that line sounds good. For documentation, I'd suggest: gcd x y is the non-negative factor of both x and y of which every common factor of x and y is also a factor; for example gcd 4 6 = 2, gcd (-4) 6 = 2, gcd (-4) (-6) = 2, gcd 0 4 = 4, gcd 0 0 = 0. (That is, the common divisor that is "greatest" in the divisibility ordering.)

4 3

Re: Libraries Digest, Vol 93, Issue 21
by John Lato 31 May '11

31 May '11

> > > Message: 3 > Date: Sun, 22 May 2011 06:52:49 -0400 > From: "Edward Z. Yang" <ezyang(a)MIT.EDU> > Subject: Re: Proposal: Value strict versions of containers > To: Milan Straka <fox(a)ucw.cz> > Cc: libraries <libraries(a)haskell.org> > Message-ID: <1306061483-sup-1713@ezyang> > Content-Type: text/plain; charset=UTF-8 > > Excerpts from Milan Straka's message of Sun May 22 06:50:07 -0400 2011: > > - the types Data.IntMap.IntMap, Data.IntMap.Lazy.IntMap and > > Data.IntMap.Strict.IntMap should be equal -- so I can use strict > > methods on IntMap someone else created with lazy methods. That is > > simple in absence of type classes. > > Comment: This would mean you would get no static assurances against > mixing up a strict IntMap with a lazy IntMap; for all intents and purposes, > this is equivalent to implementing strict versions of all functions on top > of a lazy data type. > Another consequence to this design is that, should someone want to have > class MapC m key value | m -> key, m -> value where it becomes impossible to directly write > instance MapC (Data.IntMap.Strict.IntMap Int a) Int a where > > instance MapC (Data.IntMap.Lazy.IntMap Int a) Int a where because the two instances are the same. Regardless, +1 for Milan's proposal either with one type or separate types for strict and lazy. John Lato

2 4

parallel package: minor error in the documentation of Control.Parallel.Strategies.parMap
by Tsuyoshi Ito 31 May '11

31 May '11

Hello, I think that the documentation of the parallel package version 3.1.0.1 contains a minor error (I hope that this is the right place to report such an issue). Namely, the documentation of Control.Parallel.Strategies.parMap (see http://hackage.haskell.org/packages/archive/parallel/3.1.0.1/doc/html/Contr…) contains the following remark: > parMap strat f = withStrategy strat . map f but this is incorrect. Being new to Parallel Haskell, I had been confused by this remark, wondering why this means that the elements are evaluated in parallel, until I found out that the actual implementation was: > parMap strat f = (`using` parList strat) . map f or equivalently: parMap strat f = withStrategy (parList strat) . map f Please fix the documentation. Thank you in advance. Best regards, Tsuyoshi Tsuyoshi Ito Institute for Quantum Computing, University of Waterloo http://www.cs.uwaterloo.ca/~tito/

2 1