Ben Rudiak-Gould writes:
1. Programs using the library will have predictable (exploitable) bugs in pathname handling.
2. It will never be possible to change the current weird behavior, because it might break legacy code.
I completely agree. Handling file path specifications as Strings is not a good idea. A path should be an abstract data type -- I think we all agree on that --; and if it were, it could be made an instance of Show, and all would be well. One argument against changing this has always been that it would break legacy code (as if it were a huge problem to add a 'show' call here and there). If GHC starts distributing even _more_ (broken) path manipulation functions which use String rather than something sensible, I fear that the window of opportunity for ever getting it right is shut. My suggestion would be to postpone distributing these modules until it is clear that they do work, or until someone has written something that does. The sources are readily available in CVS anyway, if you need them. Path handling is extremely tricky, especially if you want to be portable. IMHO, the subject deserves more attention before any of the existing solution should be labeled "reliable" -- and that is what shipping the code with GHC would implicitly do. Just my 0.02 Euros. Peter