[Haskell-cafe] Core packages and locale support

[Felipe Lessa]

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
> >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.