Duncan Coutts wrote:
In practise in the short term, the choice is between each application fumbling with strings in different incorrect ways or a library that fumbles with strings in a rather more considered and portable way.
Honestly I don't see a reason to bother with (++) and takeWhile and isSuffixOf when there is a way to view paths as... uhm... well, paths instead of strings. Of course, this might just be a personal preference.
Try proposing something concrete
I might. For the time being I didn't think about an actual proposal. It's just that seeing the nitpicking about corner cases of an approximate solution tripped me off somewhat.
- declare that Unix uses Unicode too, take the appropriate conversion from the locale
Sadly this does not work.
Strictly speaking it wouldn't. If I'm in a ISO-8859-15 locale and mount a KOI-8R file system, I will get garbage instead of cyrillic letters. Can't be fixed, no point in fretting about it. All other problems basically vanish as soon as (unicodeToLocale . localeToUnicode == id), and I maintain that this can be achieved by reserving 256 code points in the vendor zone for use as escape characters.
Heck, NO library fumbles with strings, neither parsers nor pretty printers nor Network... why should a FilePath be different?
For compatibility with the Haskell98 IO library.
Aww, come on, module IO isn't going to vanish soon. Instead a new one could appear: module System.IO.Sanitized where import qualified System.IO as IO import Control.Monad openFile fp mode = liftIO $ IO.openFile (fpToString fp) mode You get the idea...
There's also the issue here that adding in lots of conversions ADT <-> String means that people will not bother to use it and will continue to do things like: readFile (path ++ "/" ++ file)
import System.IO.Sanitized ... readFile (path +/+ file) ... I, for one, actually *want* to bother with an ADT. Udo. -- Did you know that if you took all the economists in the world and lined them up end to end, they'd still point in the wrong direction?