- Libraries - Haskell.org

Contribution vs quality, and a few notes on the Platform process
by Bryan O'Sullivan 23 Nov '10

23 Nov '10

Folks, I'm going to change the naming of functions in the text API to match base within the next few days, but for me this has been a close-run decision: I've come very nearly as close to simply asking for the text proposal to be withdrawn. This has been the first time in my many years of participation in the Haskell community of finding the experience thoroughly and persistently unpleasant. My reason for choosing to change the names is in part a nod of respect to Ian and Ross, whose opinions and contributions I value. I continue to disagree with their conclusion about naming, but I understand their reasoning behind it. I also want to make the volunteering jobs of Duncan, Don, and the other HP folks less onerous, as the success of their work is very important to me, and we owe them a debt of gratitude for their work. I feel a strong sense of obligation to all of these people. Now why, with all that noble sentiment expressed, would I have so strongly considered walking away over such an apparently minor point as the names of a few functions? Put it down to a matter of pride and proportion. Tom's original text library was about 1,700 lines in length. When Duncan handed it over to me, it was 2,200. It's now 12,300 lines long. I also spent three months writing a random number generator, a statistics library, and a benchmarking library in order to ensure the code was fast. And then there are the ICU bindings, for all the extra Unicode work that's simply too much to reimplement in native Haskell. Together, those libraries amount to an additional 11,300 lines of code. So. 23,600 lines of code, six BSD-licensed libraries, and months of work later, to be told repeatedly that my taste in function naming for a small portion of the API, no matter how clearly articulated, wasn't good enough has, well, not sat well with me. Sad to say, it is only by a hair's breadth that I feel like enough of a bigger man to push ahead. It has at times been difficult not to feel like I've laboured mightily over a large gift, only to have it shoved back in my face because the ribbons simply don't capture quite the right curl. Now that I've gotten that off my chest, I have some specific proposals to fix aspects of the Platform inclusion process that I found most painful. I would be most grateful to see these receive consideration. To begin with, active participation, moderation, and collation of data is important. The text proposal spawned some huge threads, but I felt that the HP team was largely absent through the many discussions, and after a while I had to simply give up tracking stuff by eyeball. Maybe I missed some things as a result; I don't know. - There must be a place for people to record issues, so we know which ones matter enough to track. Trac would work perfectly well for this. The order of operations should probably be for objectors to record their thoughts there, then for a moderator or the proposer to sort them out after a discussion period. (Obviously, in the case of text, naming looked like the squeaky wheel, but Ian raised a number of issues with bits of the internals, and I'm not sure I caught them all amid the torrent of email. And those were the ones that were actually unequivocally valuable, too!) - A moderator should keep the discussion from wandering too far off track. Things that I'd like to see as off limits would include discussion of whether some third party library needs tweaking, or an attempt to revive a contentious topic of discussion that has been resolved and should stay that way. - An Apache-style vote system for resolving points of disagreement, so that we can move past them reasonably swiftly instead of going in endless morale-sapping circles. This is particularly important to me. I'd really have liked to be able to say "we discussed this, it's over" about naming, but instead I feel that objectors held, in effect, a veto. The current consensus system seems to require complete agreement from all parties, which seems perverse. I am sad to say that I feel somewhat ill done by and upset as a result of this process, and it's not an experience I would rush to repeat. I wish you the best in improving it.

17 32

Re: Unsiged numbers (Was: RFC: Adding a Hashable type class and HashMap/HashSet data types to HP)
by Henning Thielemann 22 Nov '10

22 Nov '10

Daniel Peebles wrote: > I like this idea. As I mentioned on IRC, I'd call the class Hash rather than > Hashable. I'm also with you on the Word return type. It may be less > convenient but maybe this will be a tiny step towards the "great Word revolt" > (in which all conceptually unsigned things in the prelude and standard > libraries actually become unsigned) that I hope will occur sometime in the > near future. "Word" does not seem to be the right ... erm ... word. Modula is calling unsigned types CARDINAL. However in Modula-3 CARDINAL is a subset of INTEGER (similar to Haskell Int), in order to avoid problems with mixed signed/unsigned arithmetic. In the package non-negative I define non-negative numeric types, but I found it cumbersome to use them.

1 0

Control.Parallel.Strategies Should re-export NFData
by Thomas DuBuisson 17 Nov '10

17 Nov '10

I know NFData was previously moved out of Control.Parallel.Strategies, but it makes good sense for NFData to still be exported. Any polymorphic use of rdeepseq will require the NFData constraint and it seems silly to make users hunt-down and import another module for such a simple use case. Thoughts? Cheers, Thomas

2 1

Proposal: Improve Read Integer
by Ian Lynagh 17 Nov '10

17 Nov '10

Proposal: Improve Read Integer http://hackage.haskell.org/trac/ghc/ticket/4500 Currently, according to H98, H2010, GHC and hugs, reads "1.2" :: [(Integer, String)] is [] whereas I would expect it to be [(1,".2")] Patch: http://hackage.haskell.org/trac/ghc/attachment/ticket/4500/read-integer.dpa… Suggested deadline: 1 Dec 2010. Thanks Ian

5 7

Proposal: Add a Read instance for Data.Fixed.Fixed
by Ian Lynagh 16 Nov '10

16 Nov '10

Proposal: Add a Read instance for Data.Fixed.Fixed http://hackage.haskell.org/trac/ghc/ticket/4502 Patch and test in the ticket; the essence is: readsFixed :: (HasResolution a) => ReadS (Fixed a) readsFixed = readsSigned where readsSigned ('-' : xs) = [ (negate x, rest) | (x, rest) <- readsUnsigned xs ] readsSigned xs = readsUnsigned xs readsUnsigned xs = case span isDigit xs of ([], _) -> [] (is, xs') -> let i = fromInteger (read is) in case xs' of '.' : xs'' -> case span isDigit xs'' of ([], _) -> [] (js, xs''') -> let j = fromInteger (read js) l = genericLength js :: Integer in [(i + (j / (10 ^ l)), xs''')] _ -> [(i, xs')] Suggested deadline: 1 Dec 2010. Thanks Ian

1 0

Haskell Platform call for consensus: add transformers and revise the mtl package to depend on it
by Johan Tibell 16 Nov '10

16 Nov '10

Hi, This is a call for consensus for the following proposal: http://trac.haskell.org/haskell-platform/wiki/Proposals/transformers Are there any unresolved concerns? Deadline: 2 weeks (Nov 14) Johan

14 33

Haskell Platform decision: time to bless parsec 3?
by Don Stewart 15 Nov '10

15 Nov '10

Hey all, This is a loose end in the package policy situation: when the HP has a major upgrade, the policy is to do all major upgrades for any packages contained in the HP, as long as they don't add new dependencies. One exception to this rule has been parsec, where parsec 2 was considered "blessed" on an ad hoc basis. I propose we agree to remove this ad hoc rule, and thus the HP will ship with parsec 3. Does anyone have concerns with this? -- Don

18 24

Updating documentation
by Don Stewart 13 Nov '10

13 Nov '10

Hey all, I'm walking over the libraries@ maintained packages, updating documentation, according to a style guide I'm developing. You should see new releases of libraries@ packages with documentation-only changes in coming days and weeks. E.g. http://hackage.haskell.org/package/deepseq http://hackage.haskell.org/package/haskell-src Longer term I'm hoping to standardize the .cabal files and docs of everything in the platform. -- Don

10 17

Proposal: Add IsString and Monoid instances for Doc
by Bas van Dijk 13 Nov '10

13 Nov '10

Hello, Since we're discussing a proposal for the pretty package I would like to make another one: The proposal is to add the following to Text.PrettyPrint.HughesPJ: instance IsString Doc where fromString = text This allows users to use string literals as Doc values using the OverloadedStrings language extension. I would also like to add: instance Monoid Doc where mempty = empty mappend = (<>) If there's enough demand (because it's a lot of work) I can find out if this change breaks anything by analyzing pretty's direct reverse dependencies: http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/pretty… to see if some of them define an orphaned instance for IsString or Monoid. The patch that implements this is attached to the ticket: http://hackage.haskell.org/trac/ghc/ticket/4378 Deadline: 2 weeks (Friday 22 October 2010) Regards, Bas

2 7

Re: Nothing can link with gtk on Snow Leopard
by John Lato 11 Nov '10

11 Nov '10

> > > Hi, > > > > I'm running Mac OS X Snow Leopard. I've done a "sudo cabal install gtk > > --global" on my system, and it warns me that "file was built for > unsupported > > file format which is not the architecture being linked (i386)". What does > > this refer to? > > > > Subsequently, nothing else _links_ properly with gtk. > > > > For example, hp2any-manager (or other tools) all fail during linking with > > gtk. > > > > Am I doing something wrong? > > > > At one point I had this problem due to hsc2hs attempting to build 64-bit. > What happens if you try running: > > cabal install gtk --global --hsc2hs-flags=--cflags=-m32 > > (I think that's the incantation I used). > > Apologies for not remembering more details, but I'm strongly suspicious > that > the issue lies in hsc2hs. > Small addendum - this is assuming that gtk+ is indeed available as 32-bit, as Greg confirmed is necessary. I would check the gtk libraries with "lipo -info" to see the available architectures.

1 0