I don't know if you guys have been following this thread, but Duncan
reminded I forgot to cc this list; he also comments "How about making
a library proposal to change them to abstract newtypes,
then we can change the internal representation at will."
---------- Forwarded message ----------
From: Gwern Branwen
Date: Sun, Nov 23, 2008 at 10:53 PM
Subject: template-haskell depends on packedstring
To: libraries@haskell.org
-----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-----
