Abstract FilePath Proposal

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Abstract FilePath Proposal

Herbert Valerio Riedel
-----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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

Bardur Arantsson-2
On 06/26/2015 06:08 PM, Herbert Valerio Riedel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello *,
>
> What?
> =====
>
[--snip--]

I am *entirely* behind this in priciple and if it doesn't break too much
of Hackage, also in practice, but...

... how much of Hackage *does* this break?

The reason that I'm in favor in principle is that paths really *are*
opaque things -- platforms have entirely different conventions. AFAICT
the only thing that they seem to agree on is that there is a "hierarchy"
of some sort. (And not much else, including such things as case
(in-)sensivity or character sets.). For example, in POSIX they're just
strings of bytes without any specified encoding, and I'd love if they
could be make to work like that when dealing with files in Haskell.

Regards,


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

Herbert Valerio Riedel
On 2015-06-27 at 03:30:56 +0200, Bardur Arantsson wrote:

[...]

> I am *entirely* behind this in priciple and if it doesn't break too much
> of Hackage, also in practice, but...
>
> ... how much of Hackage *does* this break?

This won't be for free: I expect most packages which currently do more
than just opaquely pass around FilePaths to require fixes.

Some examples:

 - `writeFile "doo/foo.bar" ...`
   `_ <- readFile ("doo" </> "foo" <.> "bar")`

   This will break unless -XOverloadedStrings happens to be enabled

 - Unless we generalise (++) to (<>), all cases where `FilePath`s are
   concatenated via (++) will break.

 - Code that uses Data.List rather than the `filepath` package for
   FilePath manipulation will need fixups (simplest fix: explicitly
   convert to/from String for the manipulation)

 - Some code, like e.g.

     fnames <- System.Environment.getArgs
     forM fnames $ \fn -> print =<< readFile fn

   will inevitably need to insert explicit conversions to/from FilePaths

I tried to simulate the effect on Hackage, but this turned out to be
more time-demanding than I hoped for and I had to abort. But the above
is what I encountered in my attempt.

> The reason that I'm in favor in principle is that paths really *are*
> opaque things -- platforms have entirely different conventions. AFAICT
> the only thing that they seem to agree on is that there is a "hierarchy"
> of some sort. (And not much else, including such things as case
> (in-)sensivity or character sets.).

> For example, in POSIX they're just strings of bytes without any
> specified encoding, and I'd love if they could be make to work like
> that when dealing with files in Haskell.

Yes, if you look e.g. at

  http://hackage.haskell.org/package/unix

you see a lot of API duplication, which wouldn't have been needed if
FilePath was an opaque type w/ lossless conversion to/from
ByteString.
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

SV: Abstract FilePath Proposal

Niklas Larsson
In reply to this post by Herbert Valerio Riedel
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: [hidden email]
Skickat: ‎2015-‎06-‎26 18:09
Till: [hidden email]; [hidden email]
Ä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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: SV: Abstract FilePath Proposal

Kostiantyn Rybnikov

Because new api already exists in libraries, but FilePath from base is still being used, which makes things worse (now your programs have all those conversions all over).

I like the idea with gradual deprecation warning, but it's not clear if it's feasible to implement.

27 черв. 2015 12:33 "Niklas Larsson" <[hidden email]> пише:
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: [hidden email]
Skickat: ‎2015-‎06-‎26 18:09
Till: [hidden email]; [hidden email]
Ä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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Abstract FilePath Proposal

Neil Mitchell
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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;metaniklas@gmail.com&#39;);" target="_blank">metaniklas@...> 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: [hidden email]; [hidden email]
Ä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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: SV: Abstract FilePath Proposal

Bardur Arantsson-2
In reply to this post by Niklas Larsson
On 06/27/2015 11:33 AM, Niklas Larsson 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?
>

This is a good idea in theory, but it's how we end up in situations like

   https://xkcd.com/927/

:)

Regards,

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

David Fox-12
In reply to this post by Herbert Valerio Riedel


On Fri, Jun 26, 2015 at 9:08 AM, Herbert Valerio Riedel <[hidden email]> wrote:

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?

​I've had success with a slightly different "How":

Phase 1: Replace FilePath with a type class, with instances for the old FilePath (i.e. String) and the new implementation.

Phase 2:  Wait until a suitable amount of hackage builds without the string instance.

Phase 3: Deprecate the String instance - move it to an old-filepath package.

Phase 4: Replace the type class with the new implementation
This way the new implementation is available immediately, packages can begin converting at once, benefits can be assessed.

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

Herbert Valerio Riedel-3
On 2015-06-27 at 14:56:33 +0200, David Fox wrote:

[...]

> ​I've had success with a slightly different "How":

What was your concrete use-case btw?

> Phase 1: Replace FilePath with a type class, with instances for the old
> FilePath (i.e. String) and the new implementation.

what would that comprise in the FilePath case?

I assume adding a transitional class whose methods are not exposed (and
whose typeclass name is exported from some GHC-specific internal-marked
module)? i.e.

  class IsFilePath a where
    privateToFilePath :: a -> FilePath
    privateFromFilePath :: FilePath -> a
   
  instance IsFilePath FilePath where
    privateToFilePath   = id
    privateFromFilePath = id
   
  instance IsFilePath [Char] where
    privateToFilePath   = System.IO.toFilePath
    privateFromFilePath = System.IO.fromFilePath

?

as well as changing a lot of type-sigs in base & filepath from
e.g.

  writeFile :: FilePath -> String -> IO ()
  openTempFile :: FilePath -> String -> IO (FilePath, Handle)

to

  writeFile    :: IsFilePath a => a -> String -> IO ()
  openTempFile :: IsFilePath a => a -> String -> IO (a, Handle)


?

> Phase 2:  Wait until a suitable amount of hackage builds without the string
> instance.

I can see Stackage helping with that by using a custom GHC which lacks
the legacy `IsFilePath [Char]`-instance. So I'd be optimistic that Phase2 could be
accomplished within one year for the Stackage-subset of Hackage.

> Phase 3: Deprecate the String instance - move it to an old-filepath package.
>
> Phase 4: Replace the type class with the new implementation

I assume this means getting rid again of the typeclass, and changing the
type-sigs back to i.e.

  writeFile :: FilePath -> String -> IO ()
  openTempFile :: FilePath -> String -> IO (FilePath, Handle)

(but now with with the new opaque `FilePath`)?

> This way the new implementation is available immediately, packages can
> begin converting at once, benefits can be assessed.

This scheme seems feasible at first glance, as long as the typeclass
doesn't start spreading across packages and find its way into type-sigs
(in which case it'd become more disruptive to get rid of it
again). Otoh, I'm not sure (assuming I understood how your scheme works)
it can be avoided to have the typeclass spread, since if not every API
that now has `FilePath` arguments in their type-sigs gets generalised to
have `IsFilePath a => a` arguments instead, we can't reach the goal of
"Phase 2".

But I suspect that I didn't fully understand how your proposed
transition scheme works exactly... so please correct me where I got it
wrong!


Cheers,
  hvr
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

David Fox-12


On Sat, Jun 27, 2015 at 6:37 AM, Herbert Valerio Riedel <[hidden email]> wrote:
On 2015-06-27 at 14:56:33 +0200, David Fox wrote:

[...]

> ​I've had success with a slightly different "How":

What was your concrete use-case btw?

> Phase 1: Replace FilePath with a type class, with instances for the old
> FilePath (i.e. String) and the new implementation.

what would that comprise in the FilePath case?

I assume adding a transitional class whose methods are not exposed (and
whose typeclass name is exported from some GHC-specific internal-marked
module)? i.e.

  class IsFilePath a where
    privateToFilePath :: a -> FilePath
    privateFromFilePath :: FilePath -> a

  instance IsFilePath FilePath where
    privateToFilePath   = id
    privateFromFilePath = id

  instance IsFilePath [Char] where
    privateToFilePath   = System.IO.toFilePath
    privateFromFilePath = System.IO.fromFilePath

?

as well as changing a lot of type-sigs in base & filepath from
e.g.

  writeFile :: FilePath -> String -> IO ()
  openTempFile :: FilePath -> String -> IO (FilePath, Handle)

to

  writeFile    :: IsFilePath a => a -> String -> IO ()
  openTempFile :: IsFilePath a => a -> String -> IO (a, Handle)


?

> Phase 2:  Wait until a suitable amount of hackage builds without the string
> instance.

I can see Stackage helping with that by using a custom GHC which lacks
the legacy `IsFilePath [Char]`-instance. So I'd be optimistic that Phase2 could be
accomplished within one year for the Stackage-subset of Hackage.

> Phase 3: Deprecate the String instance - move it to an old-filepath package.
>
> Phase 4: Replace the type class with the new implementation

I assume this means getting rid again of the typeclass, and changing the
type-sigs back to i.e.

  writeFile :: FilePath -> String -> IO ()
  openTempFile :: FilePath -> String -> IO (FilePath, Handle)

(but now with with the new opaque `FilePath`)?

> This way the new implementation is available immediately, packages can
> begin converting at once, benefits can be assessed.

This scheme seems feasible at first glance, as long as the typeclass
doesn't start spreading across packages and find its way into type-sigs
(in which case it'd become more disruptive to get rid of it
again). Otoh, I'm not sure (assuming I understood how your scheme works)
it can be avoided to have the typeclass spread, since if not every API
that now has `FilePath` arguments in their type-sigs gets generalised to
have `IsFilePath a => a` arguments instead, we can't reach the goal of
"Phase 2".

But I suspect that I didn't fully understand how your proposed
transition scheme works exactly... so please correct me where I got it
wrong!

​You are right, your approach is more appropriate for use by a community.​  I missed some of the problems that would arise.


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

Boespflug, Mathieu
In reply to this post by Neil Mitchell
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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]; [hidden email]
>> Ä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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

David Turner-2
Hi,

I think it'd be more robust to handle normalisation when converting from String/Text to FilePath (and combining things with (</>) and so on) rather than in the underlying representation.

It's absolutely crucial that you can ask the OS for a filename (which it gives you as a sequence of bytes) and then pass that exact same sequence of bytes back to the OS without any normalisation or other useful alterations having taken place.

You can do some deeply weird stuff in Windows by starting an absolute path with \\?\, including apparently using '.' and '..' as the name of a filesystem component:

Because it turns off automatic expansion of the path string, the "\\?\" prefix also allows the use of ".." and "." in the path names, which can be useful if you are attempting to perform operations on a file with these otherwise reserved relative path specifiers as part of the fully qualified path.


I don't fancy shaking all the corner cases out of this. An explicit 'normalise' function seems ok, but baking normalisation into the type itself seems bad.

Cheers,

David


On 28 June 2015 at 11:03, Boespflug, Mathieu <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]; [hidden email]
>> Ä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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

Boespflug, Mathieu
In reply to this post by Boespflug, Mathieu
On 28 June 2015 at 16:34, Sven Panne <[hidden email]> wrote:
> 2015-06-28 12:03 GMT+02:00 Boespflug, Mathieu <[hidden email]>:
>>
>> why does the proposal *not* include normalization? [...]
>
>
> I think this is intentional, because otherwise we are in the IO monad for
> basically all operations. What's the normalized representation of
> "foo/bar/../baz"?

Notice that the kind of normalization I'm talking about, specified in
the link I provided, does not include this kind of normalization.
Because it requires the IO monad to perform correctly, and only on
real paths.

Here is the link again:

https://hackage.haskell.org/package/filepath-1.1.0.2/docs/System-FilePath-Posix.html#v:normalise

Full canonicalization of paths, stripping out redundant ".." and
whatnot, should certainly be done in a separate function, in IO.
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

Sven Panne-2
2015-06-28 16:47 GMT+02:00 Boespflug, Mathieu <[hidden email]>:
Notice that the kind of normalization I'm talking about, specified in
the link I provided, does not include this kind of normalization.
Because it requires the IO monad to perform correctly, and only on
real paths.

Here is the link again:

https://hackage.haskell.org/package/filepath-1.1.0.2/docs/System-FilePath-Posix.html#v:normalise
[...]

OK, then I misunderstood what you meant by "normalizing". But a question remains then: What is a use case for having equality modulo "normalise"? It throws together a few more paths which plain equality on strings would consider different, but it is still not semantic equality in the sense of "these 2 paths refer to the same dir/file". So unless there is a compelling use case (which I don't see), I don't see a point in always doing "normalise". Or do I miss something?

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

Edward Kmett-2
In reply to this post by David Turner-2
Worse there are situations where you absolutely _have_ to be able to use \\?\ encoding of a path on Windows to read, modify or delete files with "impossible names" that were created by other means.

e.g. Filenames like AUX, that had traditional roles under DOS cause weird interactions, or that were created with "impossibly long names" -- which can happen in the wild when you move directories around, etc.

I'm weakly in favor of the proposal precisely because it is the first version of this concept that I've seen that DOESN'T try to get too clever with regards to adding all sorts of normalization and this proposal seems to be the simplest move that would enable us to do something correctly in the future, regardless of what that correct thing winds up being.

-Edward

On Sun, Jun 28, 2015 at 8:09 AM, David Turner <[hidden email]> wrote:
Hi,

I think it'd be more robust to handle normalisation when converting from String/Text to FilePath (and combining things with (</>) and so on) rather than in the underlying representation.

It's absolutely crucial that you can ask the OS for a filename (which it gives you as a sequence of bytes) and then pass that exact same sequence of bytes back to the OS without any normalisation or other useful alterations having taken place.

You can do some deeply weird stuff in Windows by starting an absolute path with \\?\, including apparently using '.' and '..' as the name of a filesystem component:

Because it turns off automatic expansion of the path string, the "\\?\" prefix also allows the use of ".." and "." in the path names, which can be useful if you are attempting to perform operations on a file with these otherwise reserved relative path specifiers as part of the fully qualified path.


I don't fancy shaking all the corner cases out of this. An explicit 'normalise' function seems ok, but baking normalisation into the type itself seems bad.

Cheers,

David


On 28 June 2015 at 11:03, Boespflug, Mathieu <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]; [hidden email]
>> Ä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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

Neil Mitchell
In reply to this post by Boespflug, Mathieu
When talking about "filepath" specifically as something you prod at a
specific file system, you can think about normalisation, provided you
have a specific drive in mind. However, if you're going to do that, on
Linux it's almost better to use an inode number. I have two specific
problems with normalisation:

* You might hope for the property that after normalisation equality of
file locations is equality of FilePath values. That's not true. On
Linux you have symlinks. On Windows you have case sensitivity, which
is a property of the filesystem, not the OS. You might be able to
assume a == b ==> same a b, but you can never assume a /= b ==> not
(same a b), so normalisation doesn't really change the guarantee.

* I believe some Emacs user once told me that a//b is not the same as
a/b in some circumstances. On Windows, there are lots of programs that
require / or \. Some programs require ./foo and some require foo. The
exact path you pass to some programs gets baked into their output,
which is visible in the final release. While paths might be equal for
the purpose of asking a file system to get some bytes back, they are
often different for the other things people want to do with them, like
pass them to other programs that use the paths.



On Sun, Jun 28, 2015 at 3:47 PM, Boespflug, Mathieu <[hidden email]> wrote:

> On 28 June 2015 at 16:34, Sven Panne <[hidden email]> wrote:
>> 2015-06-28 12:03 GMT+02:00 Boespflug, Mathieu <[hidden email]>:
>>>
>>> why does the proposal *not* include normalization? [...]
>>
>>
>> I think this is intentional, because otherwise we are in the IO monad for
>> basically all operations. What's the normalized representation of
>> "foo/bar/../baz"?
>
> Notice that the kind of normalization I'm talking about, specified in
> the link I provided, does not include this kind of normalization.
> Because it requires the IO monad to perform correctly, and only on
> real paths.
>
> Here is the link again:
>
> https://hackage.haskell.org/package/filepath-1.1.0.2/docs/System-FilePath-Posix.html#v:normalise
>
> Full canonicalization of paths, stripping out redundant ".." and
> whatnot, should certainly be done in a separate function, in IO.
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

Bob Ippolito
In reply to this post by Edward Kmett-2
Normalization is a very hairy issue, which is not just platform specific but also filesystem specific. Mac OS X is probably the worst of all words in that respect, where HFS+ will do NFD normalization and may or may not have case sensitivity depending on how that partition was formatted. Network file shares and disk images may or may not have case sensitivity and can use either NFD or NFC normalization based on mount options.

Contrary to statements earlier in the thread, NFD normalization happens on HFS+ filesystems (the default) regardless of whether you're using POSIX APIs or not. It's easy to prove this to yourself by creating a file with U+00c9 (LATIN SMALL LETTER E WITH ACUTE) in the name (from any of the APIs) and you'll see it come back out (e.g. from readdir) as two code points: 'e' and then U+0301 (COMBINING ACUTE ACCENT). It'll also do some weird transformations to file names that contain byte sequences that are not valid UTF-8.



On Sun, Jun 28, 2015 at 12:05 PM, Edward Kmett <[hidden email]> wrote:
Worse there are situations where you absolutely _have_ to be able to use \\?\ encoding of a path on Windows to read, modify or delete files with "impossible names" that were created by other means.

e.g. Filenames like AUX, that had traditional roles under DOS cause weird interactions, or that were created with "impossibly long names" -- which can happen in the wild when you move directories around, etc.

I'm weakly in favor of the proposal precisely because it is the first version of this concept that I've seen that DOESN'T try to get too clever with regards to adding all sorts of normalization and this proposal seems to be the simplest move that would enable us to do something correctly in the future, regardless of what that correct thing winds up being.

-Edward

On Sun, Jun 28, 2015 at 8:09 AM, David Turner <[hidden email]> wrote:
Hi,

I think it'd be more robust to handle normalisation when converting from String/Text to FilePath (and combining things with (</>) and so on) rather than in the underlying representation.

It's absolutely crucial that you can ask the OS for a filename (which it gives you as a sequence of bytes) and then pass that exact same sequence of bytes back to the OS without any normalisation or other useful alterations having taken place.

You can do some deeply weird stuff in Windows by starting an absolute path with \\?\, including apparently using '.' and '..' as the name of a filesystem component:

Because it turns off automatic expansion of the path string, the "\\?\" prefix also allows the use of ".." and "." in the path names, which can be useful if you are attempting to perform operations on a file with these otherwise reserved relative path specifiers as part of the fully qualified path.


I don't fancy shaking all the corner cases out of this. An explicit 'normalise' function seems ok, but baking normalisation into the type itself seems bad.

Cheers,

David


On 28 June 2015 at 11:03, Boespflug, Mathieu <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]; [hidden email]
>> Ä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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

Brandon Allbery
In reply to this post by Neil Mitchell
On Sun, Jun 28, 2015 at 5:09 PM, Neil Mitchell <[hidden email]> wrote:
* I believe some Emacs user once told me that a//b is not the same as
a/b in some circumstances.

Only when typing to an interactive path prompt; it lets you reset to / without erasing the existing path prefix. This should never happen in elisp, for example.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

Alexander Berntsen
In reply to this post by Herbert Valerio Riedel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

+1.
- --
Alexander
[hidden email]
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVkPLeAAoJENQqWdRUGk8BPmAQAIIdqvoB9buiDEUEb9pdKnuf
q/+/iPo65QDTntDx8izQqHPcUt8h/f2u5JG7/S+78mTtzLkn0pkj/pQt3FjhdJwX
hcJz4KFf3IHPRndKRDeGvW21m6A3OS9hxzwyvuzGFtBca3w/xQJVruViY2jto816
YK9VCZGkSoHqkQNBsGs+mh0WKpQ7FTGjHYhytQ0+CflhssWs+auHuf1Fm7sfb62t
2shjFLjnEatv0QnD31dZfHCdSiy0I+Htc5W8boS5w6LW/uAK4QUr6PAt9TTAsYUq
vOD7naeVgcUMuUx9hAkrbaigPbGW+jd2WvDq8C5EH2FRTJnzpY/srHiy+AJA/Yae
l9DkaQxrlTCfn7JXja15Kc+Ln0T7trnc7Xq9hz6AUfM8Tf6aOvL1O03bNXgnoHVP
dAi7KiFC+lOvA37zfZk1Prk6aO5GQi9XLy4lqw9xbMayK4mztB1WTDi6UVBLXJVw
jnxOwL79SnkKt8lt3GJhtFAMV0r+NR1+bFmI/b2bSC+SVCc8lA9D91L/ZdaU+r1d
hzihRbIpl2FhryE4rwXeObymc31xQsrWlTvxLSr0v+QG/uduw77EXJhfWAX505ma
k/C+uwCi8ErBgE81bt6rsXJZfugDZcEQmV9yKZlpQ8ypxVWqhz5GVlHI7If7XYH8
e0v2AHQnrcVQOimk9jCu
=hPFP
-----END PGP SIGNATURE-----
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

Boespflug, Mathieu
In reply to this post by Neil Mitchell
Right - given that filepath is a path manipulation library, not tied
to any particular filesystem, and indeed one in which arbitrary
imaginary paths can be manipulated, any normalization under
consideration can only be that which is independent of global system
state. What does happen in practice is that people compare paths
without taking into account that a user might have written "a//b"
where you have an entry for say "a/b" in your database. Normalization
avoids these errors, but I can see the appeal of not interpreting the
byte sequences at all, and the kind of normalization that can be done
without appeal to global system state ends up being smaller than
expected anyways.

So +1 for the proposal as-is.

On 28 June 2015 at 23:09, Neil Mitchell <[hidden email]> wrote:

> When talking about "filepath" specifically as something you prod at a
> specific file system, you can think about normalisation, provided you
> have a specific drive in mind. However, if you're going to do that, on
> Linux it's almost better to use an inode number. I have two specific
> problems with normalisation:
>
> * You might hope for the property that after normalisation equality of
> file locations is equality of FilePath values. That's not true. On
> Linux you have symlinks. On Windows you have case sensitivity, which
> is a property of the filesystem, not the OS. You might be able to
> assume a == b ==> same a b, but you can never assume a /= b ==> not
> (same a b), so normalisation doesn't really change the guarantee.
>
> * I believe some Emacs user once told me that a//b is not the same as
> a/b in some circumstances. On Windows, there are lots of programs that
> require / or \. Some programs require ./foo and some require foo. The
> exact path you pass to some programs gets baked into their output,
> which is visible in the final release. While paths might be equal for
> the purpose of asking a file system to get some bytes back, they are
> often different for the other things people want to do with them, like
> pass them to other programs that use the paths.
>
>
>
> On Sun, Jun 28, 2015 at 3:47 PM, Boespflug, Mathieu <[hidden email]> wrote:
>> On 28 June 2015 at 16:34, Sven Panne <[hidden email]> wrote:
>>> 2015-06-28 12:03 GMT+02:00 Boespflug, Mathieu <[hidden email]>:
>>>>
>>>> why does the proposal *not* include normalization? [...]
>>>
>>>
>>> I think this is intentional, because otherwise we are in the IO monad for
>>> basically all operations. What's the normalized representation of
>>> "foo/bar/../baz"?
>>
>> Notice that the kind of normalization I'm talking about, specified in
>> the link I provided, does not include this kind of normalization.
>> Because it requires the IO monad to perform correctly, and only on
>> real paths.
>>
>> Here is the link again:
>>
>> https://hackage.haskell.org/package/filepath-1.1.0.2/docs/System-FilePath-Posix.html#v:normalise
>>
>> Full canonicalization of paths, stripping out redundant ".." and
>> whatnot, should certainly be done in a separate function, in IO.
>> _______________________________________________
>> Libraries mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
12