Re: [Haskell-cafe] Core packages and locale support

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