John Millikin
Thanks for the library! I'm sure it will be very useful for people dealing with internationalized applications / libraries. I have a few suggestions, which might make your library easier to use and maintain.
First, it's very common to include generated files in the tarball.
Ah. That would solve the problem of the spurious empty .hsc file.
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...
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?
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.
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/ should get a copy. [ trying that without the "--lazy" just now netted me this: darcs: bug in darcs! Another possible bug in URL.waitNextUrl: curl_multi_perform() - no running handles at src/URL.hs:243 compiled Sep 12 2009 12:18:27 I'm unable to check http://darcs.net/maintenance to see if this version is supported. If it is supported, please report this to bugs@darcs.net If possible include the output of 'darcs --exact-version'. which isn't encouraging. ]
This enables people to contribute patches more easily. I've already checked it in as a branch[3]
That was a bit premature!
-- either branch mine, or create your own trunk.
No! :-P
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. [1] I was going to do something more sophisticated with the last-modified-date, but in ghc 6.10.4 date and time handling seems to be a bit of a mess, so I abandoned it. -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2009-01-31)