On 11/7/10 6:34 PM, Kathleen Fisher wrote:
As a platform user and library developer, I'd rather that high-quality libraries like text be included in the platform
than not, even if the naming conventions are slightly different. It isn't that hard to learn the naming quirks of various libraries, and it means I can rely on the library being present in a much wider collection of haskell installations. Given the distributed nature of the development of the Haskell libraries that go into the platform, they are never going to be as coherent as they might be if a small team of people wrote all of them. But then, the scope would be much smaller and the usefulness correspondingly less.
For the record, I agree with this position regarding the meta-issue of naming conventions in the HP. While consistency is certainly a desirable goal, it is not the be-all and end-all of goals nor of naming issues. The problem of handling textual information with String is notorious, both within the community and outside of it. The lack of a clear default(!) alternative to String ends up supporting the lingering rumors that functional programming can never be as efficient as $ALGOL_BASED_LANG, which ends up harming the community as a whole. The work on ByteString was an immense step forward and has been widely embraced and blessed, but its Word8-based organization means that it is not a complete solution to the problem of properly handling textual information. The text library offers such a solution and a high-quality solution at that; it is certainly on par with ByteString, IMO. I am of the opinion that adding text to the HP and encouraging it to be widely adopted is the only sensible solution to this larger issue of correct and efficient handling of textual information. Could a different internal representation have been used? Sure. Would it be more performant? Unclear. Could the functions have been named differently? Sure. Would that be an unequivocal improvement? Unclear. Is it a high-quality library? Yes. Is it widely used? Yes. Does it fill a gap in the core libraries offered by HP? Yes. With trac.haskell.org being down I can't check what other questions are listed for what should be asked of new packages, but I think the answer to whether text should be included in HP is clear, and the uncertain possibility of coming up with more parsimonious names is not enough to dislodge the rest of the reasoning for its inclusion. -- Live well, ~wren