AFPP revival proposal
22 views
Skip to first unread message
Julian Ospald
Apr 15, 2021, 6:59:34 AM4/15/21
to core-librari...@haskell.org
Hi,
I posted my AFPP revival proposal on discourse, but haven't heard
any feedback from the current CLC yet.
https://discourse.haskell.org/t/reviving-the-abstract-filepath-proposal-afpp-in-user-space
I've since then moved forward with implementation work and am planning
to prepare patches for both unix and Win32 some time.
I'd like to hear feedback from CLC on this, since it's unlikely
that this is gonna move forward without support from unix and Win32 at
least.
Cheers,
Julian
I posted my AFPP revival proposal on discourse, but haven't heard
any feedback from the current CLC yet.
https://discourse.haskell.org/t/reviving-the-abstract-filepath-proposal-afpp-in-user-space
I've since then moved forward with implementation work and am planning
to prepare patches for both unix and Win32 some time.
I'd like to hear feedback from CLC on this, since it's unlikely
that this is gonna move forward without support from unix and Win32 at
least.
Cheers,
Julian
chessai
Apr 15, 2021, 10:07:21 PM4/15/21
to Julian Ospald, core-librari...@haskell.org
Hi Julian,
The CLC doesn't get pinged about things on the discourse, and none of us seem to have come across it yet.
I'll try to get to responding this weekend.
--
You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-core-libraries/20210415104847.sitne3lbzttgjg7x%40localhost.localdomain.
Julian Ospald
Apr 16, 2021, 6:08:37 AM4/16/21
to chessai, core-librari...@haskell.org
Excellent. I've made some progress, but the biggest challenge right now is coming up with clean types.
1. AbstractFilePath abstracts over platforms
2. WindowsFilePath / PosixFilePath are exposed newtypes in case you need to deal with platform specific paths (eg. for tar)
3. Some filepath operations however are not just dealing with filepaths, but "strings". E.g. https://hackage.haskell.org/package/filepath-1.4.2.1/docs/System-FilePath-Posix.html#v:splitSearchPath ... while not being strictly filepaths, these follow the same encoding caveats, but certain functions may or may not make sense on them (like 'isValid').
As such, the original proposal is missing a solution for this distinction. There aren't many options:
1. A type synonym: type AbstractFilePath = OsString (or vice versa). This is similar to 'type FilePath = String'. The disadvantage is that we lose the type level distinction and it's more like a hint.
2. Use another newtype. This may be unergonomic, given that they actually maintain the same invariants. AbstractFilePath does not ensure filepath validity anyway (since there is no definite list of what is allowed, only hints. Even the filesystem may have an impact on what is valid. As such we only maintain the encoding). This approach may be more interesting if AbstractFilePath had more invariants, such as relative vs absolute on type level (compare with Path and hpath libraries).
3. Provide only one type for both use cases and rename to e.g. OsString.
4. Convert non-filepath things to String or Text. This kinda goes against the original proposal of not losing the encoding information and not roundtripping through types.
I feel if the types aren't intuitive, adoption will be harder. So seemingly trivial things like type names are important.
As a reference point, rust has two types: OsString and Path: https://doc.rust-lang.org/std/path/index.html where Path is basically a thin newtype wrapper, so corresponds to option 2.
Cheers,
Julian
1. AbstractFilePath abstracts over platforms
2. WindowsFilePath / PosixFilePath are exposed newtypes in case you need to deal with platform specific paths (eg. for tar)
3. Some filepath operations however are not just dealing with filepaths, but "strings". E.g. https://hackage.haskell.org/package/filepath-1.4.2.1/docs/System-FilePath-Posix.html#v:splitSearchPath ... while not being strictly filepaths, these follow the same encoding caveats, but certain functions may or may not make sense on them (like 'isValid').
As such, the original proposal is missing a solution for this distinction. There aren't many options:
1. A type synonym: type AbstractFilePath = OsString (or vice versa). This is similar to 'type FilePath = String'. The disadvantage is that we lose the type level distinction and it's more like a hint.
2. Use another newtype. This may be unergonomic, given that they actually maintain the same invariants. AbstractFilePath does not ensure filepath validity anyway (since there is no definite list of what is allowed, only hints. Even the filesystem may have an impact on what is valid. As such we only maintain the encoding). This approach may be more interesting if AbstractFilePath had more invariants, such as relative vs absolute on type level (compare with Path and hpath libraries).
3. Provide only one type for both use cases and rename to e.g. OsString.
4. Convert non-filepath things to String or Text. This kinda goes against the original proposal of not losing the encoding information and not roundtripping through types.
I feel if the types aren't intuitive, adoption will be harder. So seemingly trivial things like type names are important.
As a reference point, rust has two types: OsString and Path: https://doc.rust-lang.org/std/path/index.html where Path is basically a thin newtype wrapper, so corresponds to option 2.
Cheers,
Julian
Julian Ospald
Apr 27, 2021, 1:54:34 PM4/27/21
to chessai, core-librari...@haskell.org
Julian Ospald
May 24, 2021, 3:23:06 AM5/24/21
to chessai, core-librari...@haskell.org
Hi,
it's been a month now and I haven't heard any feedback.
Cheers,
Julian
it's been a month now and I haven't heard any feedback.
Cheers,
Julian
chessai
May 30, 2021, 7:00:21 PM5/30/21
to Julian Ospald, core-librari...@haskell.org, Emily Pillmore
Hey Julian, I've been missing these emails. Apologies for never getting back to you. Thanks to Gershom for pinging me so I could search for them.
Indeed the original proposal is a bit too invasive. I think the new one strikes a good balance concerning non-invasiveness, and leaves us a potential path for breakage (potentially breaking base) moving forward. Furthermore I've looked at the rendered documentation and see it as a great first draft. I'm +1. I'll ping Emily directly about this and see what she thinks.
Reply all
Reply to author
Forward
0 new messages