Hi Neil, why does the proposal *not* include normalization?
There are four advantages that I see to making FilePath a datatype: 1. it makes it possible to implement the correct semantics for some systems (including POSIX), 2. it allows for information hiding, which in turn helps modularity, 3. the type is distinct from any other type, hence static checks are stronger, 4. it becomes possible to quotient values over some arbitrary set of identities that makes sense. i.e. in the case of FilePath, arguably "foo/bar//baz" *is* "foo/bar/baz" *is* "foo//bar/baz" for all intents and purposes, so it is not useful to distinguish these three ways of writing down the same path (and in fact in practice distinguishing them leads to subtle bugs). That is, the Eq instance compares FilePath's modulo a few laws. Do you propose to forego (4)? If so why so? If we're going through a deprecation process, could we do so once, by getting the notion of path equality we want right the first time? Contrary to type indexing FilePath, it seems to me that the design space for path identities is much smaller. Essentially, exactly the ones here: https://hackage.haskell.org/package/filepath-1.1.0.2/docs/System-FilePath-Posix.html#v:normalise. Best, Mathieu On 27 June 2015 at 12:12, Neil Mitchell <ndmitch...@gmail.com> wrote: > Hi Niklas, > > The function writeFile takes a FilePath. We could fork base or tell everyone > to use writeFile2, but in practice everyone will keep using writeFile, and > this String for FilePath. This approach is the only thing we could figure > that made sense. > > Henning: we do not propose normalisation on initialisation. For ASCII > strings fromFilePath . toFilePath will be id. It might also be for unicode > on some/all platforms. Of course, you can write your own FilePath creator > that does normalisation on construction. > > Thanks, Neil > > > On Saturday, 27 June 2015, Niklas Larsson <metanik...@gmail.com> wrote: >> >> Hi! >> >> Instead of trying to minimally patch the existing API and still breaking >> loads of code, why not make a new API that doesn't have to compromise and >> depreciate the old one? >> >> Niklas >> ________________________________ >> Från: Herbert Valerio Riedel >> Skickat: 2015-06-26 18:09 >> Till: librar...@haskell.org; ghc-devs@haskell.org >> Ämne: Abstract FilePath Proposal >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hello *, >> >> What? >> ===== >> >> We (see From: & CC: headers) propose, plain and simple, to turn the >> currently defined type-synonym >> >> type FilePath = String >> >> into an abstract/opaque data type instead. >> >> Why/How/When? >> ============= >> >> For details (including motivation and a suggested transition scheme) >> please consult >> >> https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath >> >> >> >> Suggested discussion period: 4 weeks >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1 >> >> iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon >> BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526 >> YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2 >> 28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn >> koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN >> qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5 >> KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+ >> NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU >> tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm >> awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv >> aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb >> HjIPRrJbVK9AABo4AZ/Y >> =lg0o >> -----END PGP SIGNATURE----- >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
