template-haskell depends on packedstring
-----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-----
On Sun, 2008-11-23 at 22:53 -0500, Gwern Branwen wrote:
-----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?
Yes. The question is if one should break the TH api just to remove this deprecated dependency. Especially when it is slated to be replaced with an improved unicode packed string type in the future. So either we break it once, or twice. Duncan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Tue, Nov 25, 2008 at 3:21 PM, Duncan Coutts wrote:
On Sun, 2008-11-23 at 22:53 -0500, Gwern Branwen wrote:
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?
Yes.
The question is if one should break the TH api just to remove this deprecated dependency. Especially when it is slated to be replaced with an improved unicode packed string type in the future.
So either we break it once, or twice.
Duncan
I don't really see why we would need to change the API; let's just make the types = String, and the conversion functions null-ops. Unless there's some sort of low-level binary API compatibility you are referring to? - -- gwern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAkkzAIMACgkQvpDo5Pfl1oIbkwCfb1Bx87CqVolvdWL0ZFOwclCa x5kAnjg+EAqUJuE+mR0KLclMS1fQPn67 =d5hQ -----END PGP SIGNATURE-----
On Sun, 2008-11-30 at 16:07 -0500, Gwern Branwen wrote:
The question is if one should break the TH api just to remove this deprecated dependency. Especially when it is slated to be replaced with an improved unicode packed string type in the future.
So either we break it once, or twice.
I don't really see why we would need to change the API; let's just make the types = String, and the conversion functions null-ops.
Ah, I see. I'd not looked that closely. It's this bit you're referring to: type OccName = PackedString mkOccName :: String -> OccName occString :: OccName -> String type ModName = PackedString mkModName :: String -> ModName modString :: ModName -> String type PkgName = PackedString mkPkgName :: String -> PkgName pkgString :: PkgName -> String Technically that's not an abstract api so changing the type alias could break programs, though I agree that it may be unlikely.
Unless there's some sort of low-level binary API compatibility you are referring to?
No, just the source level API. Duncan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Sun, Nov 30, 2008 at 5:56 PM, Duncan Coutts wrote: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAkkzI7cACgkQvpDo5Pfl1oKiKQCghkRpR7vRjyTezciI9Hv/HUFX FygAmwdCS57mUfqUc2N8Dm5ceFNC2CNn =ABN1 -----END PGP SIGNATURE----- ...
Ah, I see. I'd not looked that closely. It's this bit you're referring to:
type OccName = PackedString mkOccName :: String -> OccName occString :: OccName -> String
type ModName = PackedString mkModName :: String -> ModName modString :: ModName -> String
type PkgName = PackedString mkPkgName :: String -> PkgName pkgString :: PkgName -> String
Technically that's not an abstract api so changing the type alias could break programs, though I agree that it may be unlikely.
I would argue that it's less unlikely than richly deserved. :) (I find it difficult to imagine why a TH hacker would deliberately tunnel through the alias, personally.)
Unless there's some sort of low-level binary API compatibility you are referring to?
No, just the source level API.
Duncan
OK. Is the previous issue a fatal objection or can we just make the change and upload a new TH? -- gwern
On Sun, 2008-11-30 at 18:37 -0500, Gwern Branwen wrote:
Ah, I see. I'd not looked that closely. It's this bit you're referring to:
type OccName = PackedString mkOccName :: String -> OccName occString :: OccName -> String
type ModName = PackedString mkModName :: String -> ModName modString :: ModName -> String
type PkgName = PackedString mkPkgName :: String -> PkgName pkgString :: PkgName -> String
Technically that's not an abstract api so changing the type alias could break programs, though I agree that it may be unlikely.
I would argue that it's less unlikely than richly deserved. :) (I find it difficult to imagine why a TH hacker would deliberately tunnel through the alias, personally.)
Unless there's some sort of low-level binary API compatibility you are referring to?
No, just the source level API.
OK. Is the previous issue a fatal objection or can we just make the change and upload a new TH?
How about making a library proposal to change them to abstract newtypes, then we can change the internal representation at will. I would not object to that, but then I'm not a TH hacker and they deserve the chance to comment. Duncan
On 01/12/2008 00:04, Duncan Coutts wrote:
On Sun, 2008-11-30 at 18:37 -0500, Gwern Branwen wrote:
Ah, I see. I'd not looked that closely. It's this bit you're referring to:
type OccName = PackedString mkOccName :: String -> OccName occString :: OccName -> String
type ModName = PackedString mkModName :: String -> ModName modString :: ModName -> String
type PkgName = PackedString mkPkgName :: String -> PkgName pkgString :: PkgName -> String
Technically that's not an abstract api so changing the type alias could break programs, though I agree that it may be unlikely. I would argue that it's less unlikely than richly deserved. :) (I find it difficult to imagine why a TH hacker would deliberately tunnel through the alias, personally.)
Unless there's some sort of low-level binary API compatibility you are referring to? No, just the source level API.
OK. Is the previous issue a fatal objection or can we just make the change and upload a new TH?
How about making a library proposal to change them to abstract newtypes, then we can change the internal representation at will.
I would not object to that, but then I'm not a TH hacker and they deserve the chance to comment.
It's a simple change, and we really ought to drop the packedstring package. I'll make a proposal. Cheers, Simon
participants (3)
-
Duncan Coutts -
Gwern Branwen -
Simon Marlow