April 2010 - Libraries

template-haskell: Name fields in Info (#4025)
by adam vogt 28 Apr '10

28 Apr '10

Hello, Changing the 'Info' type to use named field syntax is for documentation purposes, though there are some drawbacks to consider: http://hackage.haskell.org/trac/ghc/ticket/4025 -- Adam Vogt

1 0

darcs patch: Make toList a member of Foldable
by Eelis van der Weegen 27 Apr '10

27 Apr '10

The toList function in Data.Foldable is currently not a member of the Foldable type class, and is consequently not specializable. This is a great shame, because for data types such as [a] and data NonEmptyList a = NonEmptyList a [a] conversion to list can trivially be implemented in O(1) instead of the generic toList's O(n). In other words, any code that directly or indirectly uses Foldable's toList on values of these types needlessly performs O(n) conversions where O(1) conversions are available. Fortunately, the solution is very simple: just make toList a member of the Foldable type class. I have attached a patch that does just this.

4 11

Re: Proposal #3999: Improved folds for Data.Map and Data.IntMap
by Roman Leshchinskiy 27 Apr '10

27 Apr '10

On 23/04/2010, at 04:36, Gwern Branwen wrote: > On Thu, Apr 22, 2010 at 12:15 PM, Roman Leshchinskiy <rl(a)cse.unsw.edu.au> wrote: >> >> Hmm, I'd love to see some real-world uses of foldl. I have no idea what to optimise it for in vector. Unfortunately, the link above doesn't give any examples. >> >> Roman > > Well, since you ask... > > $ find . -name "*.hs" -exec grep -H ' foldl ' {} \; > ~/fold.txt > $ wc ~/fold.txt > 2206 24333 225619 fold.txt That doesn't really help me, though, because I can't tell why using foldl as opposed to foldl' is essential (or even correct) in these cases. In fact, at a cursory glance a lot of them look quite leaky to me. Roman

4 7

Re: [Haskell-cafe] The 8 Most Important GSoC Projects]
by Stephen Tetley 26 Apr '10

26 Apr '10

> dons at galois > We may not have a PVP checker yet, but here's a start. Hello Don I've started working on this again. Its going to be an 'API diff tool' rather than a checker, there are good technical reasons for lower ambitions. Hopefully I'll have some results by the end of the month, I'll post back to the list with a status message. Best wishes Stephen

2 1

ANNOUNCE: time-1.2
by Ashley Yakeley 26 Apr '10

26 Apr '10

I've uploaded time-1.2 to Hackage. Differences from 1.1.4: * Data instances for all types, where supported. * Some parsing code and Read instances are removed when Rank2Types is not supported. The feature support calculation is a bit fiddly and may be wrong. I've tested it with GHC 6.10.4 and 6.12.1, but not anything that doesn't support Rank2Types. -- Ashley Yakeley

3 5

[stephen.tetley@gmail.com: Re: [Haskell-cafe] The 8 Most Important GSoC Projects]
by Don Stewart 25 Apr '10

25 Apr '10

We may not have a PVP checker yet, but here's a start. ----- Forwarded message from Stephen Tetley <stephen.tetley(a)gmail.com> ----- Date: Thu, 1 Apr 2010 22:40:06 +0100 From: Stephen Tetley <stephen.tetley(a)gmail.com> Cc: haskell-cafe(a)haskell.org Subject: Re: [Haskell-cafe] The 8 Most Important GSoC Projects Hello All I had a little experiment along the lines of "A Package Versioning Policy Checker" a few months ago. I got as far as using Haskell-src-exts to extract module export list, but didn't work out out a hashing scheme for the actual type signatures. The project is minimal, but it does have code to reconcile module paths from a Cabal file using the Distribution library (which was more work than I imagined). It might make a reasonable starting point if someone wants to pick it up - afraid I'm not a student nor could I commit to being a mentor. http://copperbox.googlecode.com/files/precis-0.1.0.tar.gz Best wishes Stephen _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ----- End forwarded message -----

1 0

extensible-exceptions 0.1.1.1 fails to build on GHC 6.8 (Cabal 1.2)
by Anders Kaseorg 25 Apr '10

25 Apr '10

http://hackage.haskell.org/trac/ghc/ticket/3931 With ghc 6.8.2 on Debian lenny, with Cabal-1.2.3.0 and cabal-install-0.4.0: $ cabal install extensible-exceptions Downloading 'extensible-exceptions-0.1.1.1'... Warning: Unknown fields: bug-reports (line 6) Fields allowed in this section: name, version, cabal-version, build-type, license, license-file, copyright, maintainer, build-depends, stability, homepage, package-url, synopsis, description, category, author, tested-with, data-files, extra-source-files, extra-tmp-files Warning: Unknown section type: source-repository ignoring... Warning: Ignoring trailing declarations. cabal: cannot satisfy dependency Cabal>=1.6 This is a regression from extensible-exceptions-0.1.1.0, which worked fine. Since compatibility with GHC < 6.10 is the entire point of the extensible-exceptions package, this should probably be fixed. The patch attached to the ticket fixes this by removing source-repository from the Cabal file and lowering the Cabal requirement back to >=1.2. (Cabal 1.2 would actually accept the package with a warning if the source-repository section was moved to the bottom, but cabal check does not know that, so the package could not be uploaded to Hackage that way. See http://hackage.haskell.org/trac/hackage/ticket/639 .) Anders

3 7

Re: Adding Network.URI.escape
by Gwern Branwen 25 Apr '10

25 Apr '10

On Tue, Jan 5, 2010 at 10:18 AM, Graham Klyne <GK-lists(a)ninebynine.org> wrote: > Ironically, even the standards groups have problems with these issues. > Cf. http://lists.w3.org/Archives/Public/uri/2010Jan/0001.html > > Gwern Branwen wrote: >> >> Yes, it does demonstrate that the task is difficult and messy. As it >> is, the danger can easily be breezed through by someone who wants to >> get a job done - and that's just not the Haskell way! >> Can we leave the task to you? Even just your escapeHttpOrFileUri is an >> improvement. > > I can't promise a deadline by which this will be achieved, but I am prepared > to add it to my TODO list... > > #g Out of curiosity, has any progress been made since? -- gwern

1 0

Re: [Haskell-cafe] Re: Announcement: Data.ISO3166_CountryCodes version 0.1
by John Millikin 25 Apr '10

25 Apr '10

On Sun, Apr 25, 2010 at 01:08, Jon Fairbairn <jon.fairbairn(a)cl.cam.ac.uk> wrote: > John Millikin <jmillikin(a)gmail.com> writes: >> This allows users to install the package, without installing 3rd-party >> utilities, or downloading (possibly varying) versions from external >> websites. As your library is currently written, two users who install >> it might end up with dramatically different modules, depending on the >> contents of < http://www.iso.org/iso/iso3166_en_code_lists.txt >. > > It would take a major global political ructions to make them > /dramatically/ different, but I'm aware of the issue... Well, say some country changes its name, and thus its code. Or some small country decides to join a larger one. Generated modules will then have different sets of constructors, but the same version number, violating the package versioning guidelines. >> Second, since the module is based on an external data set, a >> date-based version might more appropriate. "Version 0.1" means >> nothing, but "version 2010.4.24" indicates when the given version was >> generated. Alternatively, you can use a hybrid system to indicate both >> stability and the date -- such as 0.1.20100424. > > Something like this is already on my TODO list, but the date > that I want to appear in the version number would be the > last-modified-date of the downloaded code-list. How do I get > that (which the build already puts into a file¹) into the .cabal > file? You could generate the .cabal file also, but it would probably just be easier to check last-modified and set the version number directly. >> Third, if you'd like your module to be widely used in the Haskell >> community, the BSD3 or MIT license would be more appropriate. For >> technical reasons, the GPL and LGPL are essentially equivalent for >> Haskell packages. For political reasons, choosing the GPL will reduce >> your user market to free-software users. This isn't *necessarily* bad >> -- all of my large projects are GPL'd -- but be aware that your choice >> will heavily limit how many people use your library. > > Something close GPL is what I want -- if I'm doing this for > openly and for nothing, I don't see why anyone should build > something on the back of it and make it proprietary without me > having a say. I'd be happy to put a notice somewhere to the > effect that I'm willing to negotiate terms for a separate > license for inclusion in proprietary code, though I'd like to > know the proper way of doing that. That's fine, but be aware that it'll make your stated goal of "I think anything that uses country codes should use this datatype!" rather difficult to achieve. Many Haskell developers seem to oppose the GPL -- for example, see the comments when I released GPL'd bindings to CPython: < http://www.reddit.com/r/haskell/comments/ajbvb/cpython_haskell_ffi_bindings… > >> Fourth, consider storing your code in a version control system (like >> Darcs[1]), > > it already is. > >> and publishing it on a website like Patch-Tag[2]. > > I was waiting for it to be uploaded overnight. If my rsync > system isn't configured to delete it next time, > > darcs get --lazy http://www.cl.cam.ac.uk/~jf15/ISO3166_CountryCodes/ Ah -- there was no source repository stanza in the Cabal file, so I'd assumed it hadn't been checked into version control yet. I've rebased my repository upon yours, and attached the Darcs bundle for my changes to this email. >> Finally, instead of using a Makefile to build the library or >> documentation, consider using the cabal-install utility[4]. It's much >> more common for a library to use "cabal build" or "cabal haddock" than >> custom make commands, and external tools (such as Hackage) will work >> better. > > I'd be grateful for a patch (against my repo) that did that. > I've used make for thirty years, so learning something else > doesn't hold great appeal. Cabal doesn't replace Make -- it just defines some basic commands for compiling, building the documentation, etc. This allows Caballized packages to be installed on a variety of systems, which might not have a sane version of Make installed. Usually, this is sufficient to build all but the most complex of packages (eg, Gtk2Hs).

1 0

Add everywhereM' to Data.Generics.Schemes
by Maciej Podgurski 25 Apr '10

25 Apr '10

Hello, as an analogue to everywhere', I suggest adding everywhereM' to Data.Generics.Schemes. The implementation would be everywhereM' :: Monad m => GenericM m -> GenericM m everywhereM' f x = do { x' <- f x; gmapM (everywhereM' f) x' } Best wishes, Maciej

4 4