Re: [Haskell-cafe] Hackage Package Discoverability

2012-10-23 Thread Bryan O'Sullivan
On Tue, Oct 23, 2012 at 5:53 AM, Myles C. Maxfield myles.maxfi...@gmail.com
 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.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Hackage Package Discoverability

2012-10-23 Thread Myles C. Maxfield
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 b...@serpentine.com wrote:

 On Tue, Oct 23, 2012 at 5:53 AM, Myles C. Maxfield myles.maxfi...@gmail.com 
 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.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Hackage Package Discoverability

2012-10-23 Thread Gwern Branwen
On Tue, Oct 23, 2012 at 1:53 AM, Myles C. Maxfield
myles.maxfi...@gmail.com wrote:
 Is there a better way to make this algorithm discoverable?

How about deprecation pragmas?
http://www.haskell.org/ghc/docs/7.2.2/html/users_guide/pragmas.html

-- 
gwern
http://www.gwern.net

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Hackage Package Discoverability

2012-10-22 Thread Myles C. Maxfield
Hello,
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.

However, I would also like to solve the discoverability problem of people
not knowing to look in the 'encoding' package when they're looking for the
punycode algorithm. (I certainly didn't look there, and as a result, I
re-implemented the algorithm). My initial thought is to keep my package in
the hackage database, but put a big label on it saying DEPRECATED: Use
Data.Encoding.BootString instead. Is there a better way to make this
algorithm discoverable?

Thanks,
Myles
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe