July 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 for template-haskell: Make Q an instance of Applicative
by Bas van Dijk 27 Jul '11

27 Jul '11

Hello, The Q type: newtype Q a = Q { unQ :: forall m. Quasi m => m a } currently has an instance for Monad and Functor. I would like to propose adding an instance for Applicative as well. Note that this also means that the Quasi class needs to get an Applicative superclass: class (Monad m, Applicative m, Functor m) => Quasi m where ... Discussion period: 2 weeks. Regards, Bas

3 3

Proposal: Add an analogue of $! to deepseq
by Ivan Lazar Miljenovic 14 Jul '11

14 Jul '11

I propose we add a operator - tentatively labelled $!! (and which Hayoo reports isn't currently exported by a Hackage package) - as a deepseq analogue $! to the deepseq library: ($!!) :: (NFData a) => (a -> b) ->a -> b f $!! x = x `deepseq` f x infixr 0 $!! As a sub-proposal, I also propose that we add a "force" function (the name of which also seems to be unused) to make it easier to test forcing of values: force :: (NFData a) => a -> a force x = x `deepseq` x Discussion time: 2 weeks -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

6 7

Changes to Data.Typeable
by Simon Marlow 14 Jul '11

14 Jul '11

Hi folks, In response to this ticket: http://hackage.haskell.org/trac/ghc/ticket/5275 I'm making some changes to Data.Typeable, some of which affect the API, so as per the new library guidelines I'm informing the list. The current implementation of Typeable is based on mkTyCon :: String -> TyCon which internally keeps a table mapping Strings to Ints, so that each TyCon can be given a unique Int for fast comparison. This means the String has to be unique across all types in the program. Currently derived instances of typeable use the qualified original name (e.g. "GHC.Types.Int") which is not necessarily unique, is non-portable, and exposes implementation details. The String passed to mkTyCon is returned by tyConString :: TyCon -> String which lets the user get at this non-portable representation (also the Show instance returns this String). So the new proposal is to store three Strings in TyCon. The internal representation is this: data TyCon = TyCon { tyConHash :: {-# UNPACK #-} !Fingerprint, tyConPackage :: String, tyConModule :: String, tyConName :: String } the fields of this type are not exposed externally. Together the three fields tyConPackage, tyConModule and tyConName uniquely identify a TyCon, and the Fingerprint is a hash of the concatenation of these three Strings (so no more internal cache to map strings to unique Ids). tyConString now returns the value of tyConName only. I've measured the performance impact of this change, and as far as I can tell performance is uniformly better. This should improve things for SYB in particular. Also, the size of the code generated for deriving Typeable is less than half as much as before. === Proposed API changes === 1. DEPRECATE mkTyCon mkTyCon is used by some hand-written instances of Typeable. It will work as before, but is deprecated in favour of... 2. Add mkTyCon3 :: String -> String -> String -> TyCon which takes the package, module, and name of the TyCon respectively. Most users can just derive Typeable, there's no need to use mkTyCon3. In due course we can rename mkTyCon3 back to mkTyCon. Any comments? Cheers, Simon

4 11

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

Proposal for deepseq: Data.Sequence.Seq instance for NFData
by Alexey Karakulov 12 Jul '11

12 Jul '11

My proposal is qiute straightforward. The patch is attached and it's essence is in these lines: > instance NFData a => NFData (Data.Sequence.Seq a) where > rnf = rnf . Foldable.toList [Discussion part] I choosed toList method to keep the code style, but I'm not sure it's efficient to create cons'es when we could just fold: > rnfFoldable :: (NFData a, Foldable f) => f a -> () > rnfFoldable = Foldable.foldMap rnf Or it's better to do this with foldl (while not so nice at is was with using () as monoid): > rnfFoldable = Foldable.foldl (const rnf) () There was a proposal to add strict folds to Foldable type class, so we can use foldl' there. My proposal is to add the instance in either way.

1 1