It is mostly because those libraries are far older than Text and ByteString, so String was the only choice at the time. Modernizing them is good.. but would also break a lot of code. And in many core libraries, the functions are required to have String types in order to be Haskell 98 compliant.
So, modernization is good. But also requires significant effort, and someone willing to make that effort. Also, URIs are not defined in terms of octets.. but in terms of characters. If you write a URI down on a piece of paper -- what octets are you using? None.. it's some scribbles on a paper. It is the characters that are important, not the bit representation. If you render a URI in a utf-8 encoded document versus a utf-16 encoded document.. the octets will be different, but the meaning will be the same. Because it is the characters that are important. For a URI Text would be a more compact representation than String.. but ByteString is a bit dodgy since it is not well defined what those bytes represent. (though if you use a newtype wrapper around ByteString to declare that it is Ascii, then that would be fine). - jeremy On Sat, Mar 10, 2012 at 9:24 PM, Jason Dusek <jason.du...@gmail.com> wrote: > The content of URIs is defined in terms of octets in the RFC, > and all Posix interfaces are byte streams and C strings, not > character strings. Yet in Haskell, we find these objects exposed > with String interfaces: > > > :info Network.URI.URI > data URI > = URI {uriScheme :: String, > uriAuthority :: Maybe URIAuth, > uriPath :: String, > uriQuery :: String, > uriFragment :: String} > -- Defined in Network.URI > > > :info System.Posix.Env.getEnvironment > System.Posix.Env.getEnvironment :: IO [(String, String)] > -- Defined in System.Posix.Env > > But there is no law that environment variables must be made of > characters: > > :; export x=$'\xFF' ; echo -n $x | xxd -p > ff > :; locale > LANG="en_US.UTF-8" > > That the relationship between bytes and characters can be > confusing, both in working with UNIX and in dealing with web > protocols, is undeniable -- but it seems unwise to limit the > options available to Haskell programmers in dealing with these > systems. > > -- > Jason Dusek > pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe