On Sun, Jun 27, 2010 at 02:52:54AM +0300, Roman Beslik wrote: > On 26.06.10 16:34, Alexey Khudyakov wrote: > >On Sat, 26 Jun 2010 10:14:50 -0300 > >Felipe Lessa<felipe.le...@gmail.com> wrote: > >>On Sat, Jun 26, 2010 at 05:01:06PM +0400, Bulat Ziganshin wrote: > >>>but what you propose cannot be used in Windows at all! while current > >>>FilePath still works on Unix, with manual filenames en/decoding > >>Now we got back on topic! :) > >> > >>The FilePath datatype is OS-dependent and making it abstract > >>should be at least a first step. If you got it from somewhere > >>else where it is already encoded, then fine. If you need to > >>construct it, then you need to use a smart constructor. If you > >>need to show/print it, then you need to convert it to String. > >>And so on. > >> > >It should solve most of problems I believe. But such change will break > >a lot of programs maybe most of them. How could one introduce such a > >change? One variant is to create new hierarchy and gradually deprecate > >old. > > I fail to see how it will brake programs. Current programs do not > use Unicode because it is implemented incorrectly.
For example, this program would break: import System.Environment (getArgs) main :: IO () main = getArgs >>= \[a] -> writeFile a "hello world" The types are: getArgs :: IO [String] writeFile :: FilePath -> String -> IO () Right now we have type FilePath = String so the code above works. If we had data FilePath = ... then that would be a type error work at all. So even one of the most trivial programs wouldn't compile anymore. Cheers, -- Felipe. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe