The last revision of the encoding package (0.6.7.1) was uploaded 6 days ago, so it's certainly not old. The package is also not unwieldly: the functions (runPut . encode punycode) and (runGet (decode punycode)) are equivalent to my 'encode' and 'decode' functions. In addition, it supports many more kinds of encodings and is much more general than my little library. In addition, it is much more flexible because of its use of ByteSource and ByteSink. It seems like a hands-down win to me. I've CC'ed the maintainer of the encoding package; maybe he can better reply about the encoding library. On Mon, Oct 22, 2012 at 11:14 PM, Bryan O'Sullivan wrote:

On Tue, Oct 23, 2012 at 5:53 AM, Myles C. Maxfield wrote:

...

I am the author/maintainer of the 'punycode' hackage package. After 4 months, I just found that punycode conversion already exists in the Data.Encoding.BootString package inside the 'encoding' package. I'd like to deprecate my package in favor of the 'encoding' package.

Please don't plan to do that. The encoding package may have filled a gap at some point, but now it looks old, unwieldy, inefficient (String), and weird (implicit parameters?) to me, and it's mostly obsolete (the standard I/O library has supported Unicode and encodings for a while now). I would not use the encodings package myself, for instance.

Your punycode package, in contrast, has a simple API and looks easy to use. I'd suggest that you supprt the Text type as well as String, but otherwise please keep it around and maintain it.