Proposal: splitting the network package

Graham Klyne GK at
Thu Jan 17 10:20:17 CET 2013

Hi all,

I'm late picking up on this.  I agree the Parsec dependency means it makes sense 
to separate the URI package from other network functions.  I don't know if 
there's a strategy for backwards compatibility of existing software that uses 

On 09/01/2013 12:17, Conrad Parker wrote:
> Yes, but then the "uri" package currently only defines one module, Text.URI:
> which is mostly similar and incompatible with Network.URI:
> Network.URI more completely implements the RFCs in that it handles
> relative and absolute URIs, and URI normalization.
> Text.URI includes a few functions for parsing (key,value) pairs for
> CGI query parameters, which iirc is not actually part of the URI
> specification, but rather part of the CGI conventions. I think these
> query parameters are better handled by the "cgi" package, or by any of
> the web frameworks (Yesod, Snap etc.).
> I think the only sensible way to use the "uri" package name would be
> to replace it (ie. remove Text.URI and add Network.URI).

FWIW, when I originally implemented URI, the interface was based on an existing 
package, but I don't recall exactly which.  Some changes were made to 
accommodate additional functionality, but with new function names.  Old function 
names were retained, but deprecated, for backwards compatibility.

I mention this because it suggests a possibility that the newer package might be 
tweaked to be a possible compatible replacement for the other.

At this stage in Haskell/HP life, I'd place a high premium on backwards 
compatibility - having existing software break because other packages don't pay 
sufficient attention to this issue is a factor that IMO impedes wider take-up of 
Haskell as a serious application development platform.  I see this discussion is 
a symptom of that.


More information about the Libraries mailing list