June 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 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: IntMap.differenceKeysSet for removing an IntSet of keys
by Liyang HU 13 Jul '11

13 Jul '11

Ticket: http://hackage.haskell.org/trac/ghc/ticket/5242 Currently, IntMap.difference ma mb removes all the keys in mb from ma, where the elements of the two IntMaps can be of different types; the elements of mb are not used. There is no efficient way to remove an IntSet of keys, however. These patches adds the IntMap.differenceKeysSet function—essentially a copy/paste of difference—that satisfies the following property: prop_DiffKeysSet :: Map Int -> Map () -> Bool prop_DiffKeysSet t1 t2 = difference t1 t2 == differenceKeysSet t1 (keysSet t2) Cons: Not so happy with the name. Code bloat. Thanks, /Liyang

5 11

Re: PROPOSAL: add tryFdSeek to unix
by wren ng thornton 30 Jun '11

30 Jun '11

On 6/29/11 3:18 PM, Simon Marlow wrote: > I think it would make sense to refactor the unix package into a very > thin "just the foreign imports" layer, and then the current unix as a > layer on top of that. Now that you mention it, I think that'd actually be really nice. On the one hand, a lot of unix is just hsc2hs code for accessing C-bits; on the other hand, a lot of unix is the various wrappers to provide a more Haskell-like interface to C. Speaking technically, the former is the hard part since it involves dealing with cross-platform and other compatibility issues. Though the latter is clearly more challenging as an aesthetic/ergonomic problem; which are too often overlooked in programming. It's very sensible to handle the different problems in different packages. > It doesn't make a great deal of sense to do this for just one function, > though. It would stick out like a sore thumb in the API. True. FWIW, the String-based API in System.Posix.IO already exposes some relatively raw wrappers to C. But even System.Posix.IO is just one module, which would still stick out considering how many modules unix has. -- Live well, ~wren

1 0

Re: PROPOSAL: add tryFdSeek to unix
by John Lato 29 Jun '11

29 Jun '11

> > I'd like to propose adding a variant of fdSeek which returns errors > > directly instead of throwing an exception. > > > > Why wouldn't you just wrap it in Control.Exception.try instead? And what's > so special about seeking that suggests that it needs an alternate entry > point? > (Disclosure: I'm one of the people who requested this originally) Wrapping a function like `fdSeek` in a `try` to get a non-exception variant is wasteful. Exceptions are a Haskell layer on top of the more fundamental library call, and people who want access to that call directly shouldn't have to unwrap extra cruft to do so. Nor should they have to re-implement basic functionality because the library doesn't expose it. fdSeek just happens to be a current need of mine. I would hope that this approach would be adopted across the board. > > (In other words, I'm opposed to this proposal.) > I'm opposed to exceptions, but there's no way to avoid them because the library doesn't expose a direct interface. John

4 4

Error in documentation for Control.Exception (base-4.*)
by Ivan Lazar Miljenovic 29 Jun '11

29 Jun '11

This was caught by mbuf on #haskell: the example for the Exception class in Control.Exception as of base-4 needs some extra escaping for Haddock markup. It currently has: @ *Main> throw ThisException `catch` \e -> putStrLn (\"Caught \" ++ show (e :: MyException)) Caught ThisException @ It should be (untested; I'm not sure of the backticks but I think it'll work): @ *Main> throw ThisException \`catch\` \\e -> putStrLn (\"Caught \" ++ show (e :: MyException)) Caught ThisException @ It may even be better to use the new support for examples in Haddock (section 3.8.5 of http://www.haskell.org/haddock/doc/html/ch03s08.html ): @ >>> throw ThisException \`catch\` \\e -> putStrLn (\"Caught \" ++ show (e :: MyException)) Caught ThisException @ -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

2 1

Re: PROPOSAL: add tryFdSeek to unix
by wren ng thornton 29 Jun '11

29 Jun '11

On 6/29/11 1:44 AM, Bryan O'Sullivan wrote: > On Tue, Jun 28, 2011 at 5:15 PM, wren ng thornton<wren(a)freegeek.org> wrote: >> I'd like to propose adding a variant of fdSeek which returns errors >> directly instead of throwing an exception. > > Why wouldn't you just wrap it in Control.Exception.try instead? And what's > so special about seeking that suggests that it needs an alternate entry > point? > > (In other words, I'm opposed to this proposal.) Why should it be wrapped? Why not have the error throwing variants be wrappers that case match against the Either? There's nothing special about seeking, per se. But not everyone is enamored of the exception system. In particular, libraries like iteratee already have their own FFI bindings in order to work around this limitation with the unix library. You'd have to ask John Lato and Oleg whether it is more because of performance issues or philosophical/linguistic issues. The point is, there are people already not using unix because of this. And, as mentioned in the proposal, there _is_ nothing special about seeking; the same API is being provided by unix-bytestring for reading and writing. The only reason for proposing this to unix is because System.Posix.IO is the appropriate home, and putting it there instead of another module will minimize transition issues once unix-bytestring is (eventually) rolled into unix. -- Live well, ~wren

2 1