AFPP

[hasufell]

TODO:

• add Data.ByteString.Short.Word16 (see Add Data.ByteString.Short.Word16 and friends #102)
• add internal filepath variants for ShortByteString (unix) and ShortByteString based on UTF16 (windows)
• add the actual AFPP types from https://github.com/hasufell/abstract-filepath/tree/master/abstract-filepath-types
  • a big question here is if the types should actually live in filepath or somewhere else?
• fix tests for emulated arches (due to old bytestring)
• add variants for PosixFilePath, WindowsFilePath and AbstractFilePath (do we also want a platform-dependent one for PlatformFilePath or is that redundant?), see https://github.com/hasufell/abstract-filepath/tree/master/abstract-filepath/lib/AFP/AbstractFilePath ...these will just be ctor unpacking shims
• test equivalence to old version

---

Post-PR tasks:

• PR to unix: Add PosixFilePath and friends support (for AFPP) unix#202
• PR to Win32: Add WindwowsString/WindowsFilePath support wrt AFPP win32#198
• create a companion package for readFile, openFile etc.: https://github.com/hasufell/file-io

---

Live haddock:

• https://hasufell-stuff.eu-central-1.linodeobjects.com/filepath/index.html

[hasufell]

@Bodigrim it's still not clear to me where the types should live. If they live here, it's gonna cause problems for some packages. Any package that filepath depends on will not be able to import AbstractFilePath types.

That currently is:

        , bytestring >= 0.11.3.0
        , deepseq
        , exceptions
        , text
        , template-haskell

with the testsuite a bit more.

If we move the types somewhere else, the instances (like IsString) will either have to be orphan instances, because they require System.FilePath.Data.ByteString.Short.Decode and System.FilePath.Data.ByteString.Short.Encode, or we will have to inline those functions with the types.

[Bodigrim]

@hasufell deepseq, exceptions and template-haskell do not care about AbtractFilePath much. text potentially does, but locale-dependent Data.Text.IO and friends are an antipattern any way. bytestring is more problematic, because it has decent set of file manipulations, but there is probably no work around this.

What if filepath itself provides functions similar to Data.Bytestring.{,Lazy.}{readFile,writeFile,appendFile} and Data.ByteString.Builder.writeFile, but with AbstractFilePath instead of FilePath? Relevant bytestring documentation could suggest using them instead.

[hasufell]

What if filepath itself provides functions similar to Data.Bytestring.{,Lazy.}{readFile,writeFile,appendFile} and Data.ByteString.Builder.writeFile, but with AbstractFilePath instead of FilePath? Relevant bytestring documentation could suggest using them instead.

So far, filepath has mostly avoided having IO functions at all, except for getSearchPath.

Additionally, we cannot use base provided functions to open files, because they don't support AbstractFilePath. We'd have to depend on unix and Win32, which of course is not possible. They have to depend on us.

[Bodigrim]

This is massive, great work! I skimmed through, but I'm out of my depth in filepath-specific questions.

[Bodigrim]

These two names are a bit cryptic, but I'm bad with naming.

[hasufell]

I think pstr is ok for this, because it's the name for the quasiquote, which really should be short to avoid annoyances.

bsToPlatformString expanded would be byteStringToPlatformString... which gives me headache :p

[Bodigrim]

Not #ifdef WINDOWS?

[hasufell]

WINDOWS macro is only used to generate platform-specific modules (no matter the current platform), because we want to be able to deal with with both posix and windows specific filepath on all platforms. defined(mingw32_HOST_OS) || defined(__MINGW32__) is used to select the implementation for AbstractFilePath and PlatformFilePath.

[Bodigrim]

Why do you need phase control [0] here?

[hasufell]

I don't actually know if this makes any difference.

[hasufell]

openFile and friends for abstract filepath are implemented here: https://github.com/hasufell/file-io

It is much shorter than the base versions. It uses unix and Win32. Whether the implementation is really equivalent to base, I don't know. I've done some manual testing (e.g. that lazy readFile "foo" >>= writeFile "bar" does not force and that windows doesn't keep files locked). For the file contents, all functions use ByteString.