[Haskell-cafe] Core packages and locale support
felipe.lessa at gmail.com
Sat Jun 26 21:01:57 EDT 2010
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.lessa at 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
> 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.
More information about the Haskell-Cafe