-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 So I was trying to compile lambdabot with cabal-install. Lambdabot uses Template Haskell for generating some boilerplate, and it was a failed dependency. Template Haskell uses packedstring for... something... and packedstring was a failed dependency: Data/PackedString.hs:83:7: Could not find module `Data.Data': it is a member of package base, which is hidden Now this is a problem, but it's not the problem I am interested in. I am interested in: why is template-haskell using packedstring? Wasn't packedstring obsoleted years ago? I downloaded the TH tarball to see what fascinating things it was using packedstring for, and I found that it's hardly doing anything - it apparently is just encoding module (ModName) and OccName (whatever that is), and then the other functions shift back from PackedString/ModName-OccName to String. (This is all in Language/Haskell/TH/Syntax.hs) I replaced all the PackedString stuff with normal ol' String and compiled fine, and indeed seems to work fine at Template-Haskelly stuff. So here's my suggestions: 1) Remove the packedstring dep and calls from the TH code. It is useless, it shackles the package to a long obsolete one, and so on. Even if we assume that the packedstring code is still faster than native String, and that there's no performance penalty for the conversions back and forth from String to PackedString, and that the possible size increase from linking in PackedString code is not worth worrying about, and we also assume that PackedString is being used on Names large enough to make up for any overhead - even if we assume all that, TH is a compile-time process and so it doesn't matter all that much if we shave a few microseconds off one small part of the compilation process. Installability and cleaner code would be worth that price. 2) If just String is not acceptable, then I understand from dons that the reason we can't use just plain ol' ByteString is because the Names may well be in UTF-8, and ByteString's [Word8]s apparently don't treat that well. Given that, we need some sort of UTF8 bytestring. As it happens, we do in fact have such a thing: Data.ByteString.UTF8 . It looks a bit incomplete, but utf8-string in general is pretty widely-used and reliable (also builds on 6.10): just about every XMonad user uses XMonadContrib which uses utf8-string, and I can count the number of complaints because utf8-string on one hand. Thoughts? I searched thoroughly through various bug-trackers and mailing lists, but this doesn't seem to've come up before. - -- gwern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAkkqJTsACgkQvpDo5Pfl1oLYoQCgjRSqno+DtyZiLbAS5Pk4l8Ao sqkAn15sBq+alBy5ZVLHIMthjZ6eU6E6 =N8Qj -----END PGP SIGNATURE-----