"FastPackedString" considered harmful

[Donald Bruce Stewart]

seth:
> I agree with Don about the current name.  If FastPackString is confusing because it isn't a string, doesn't ByteString suffers from the same problem?

I'm not sure if you're agreeing with me Seth :)

I do think FastPackedString is not a suitable for a standard Haskell
library as long as it only works on byte strings. So, to make crystal
clear what the story is, I propose ByteString, following IntMap, to
state this. I think its important to keep 'String' in the name, since
its a string-mangling library.

> Seth
> 
> On Thu, 20 Apr 2006 13:26:27 +1000
> dons at cse.unsw.edu.au (Donald Bruce Stewart) wrote:
> 
> > 
> > On the topic of a good name for FPS, I think its fairly widely
> > considered that a packed byte "string" shouldn't be considered a String,
> > and thus FastPackedString is a potentially confusing misnomer.
> > It was always meant as a working title until something replaced
> > Data.PackedString anyway.
> > 
> > If this library is to be imported into the base libraries, along with
> > future PackedString.Unicode and so on, layers on top, we should probably
> > get the name right now.
> > 
> > I'm disinclined to call it a ByteArray module -- it doesn't really offer
> > array-like operations. And its got nothing much to do with the other
> > Array.* stuff.
> > 
> > Instead, how about: Data.ByteString  (with a connotation of IntMap) ?
> > 
> > That seems to suggest both the stringy-ness of the api, but also the
> > restriction to bytes.
> > 
> > -- Don
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://www.haskell.org/mailman/listinfo/libraries
> > 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries