Description
Motivation
The next filepath release will add support for a new API, which fixes subtle encoding issues and improves cross platform code and memory residence.
You can read about the state of the newly added API here: haskellfoundation/tech-proposals#35
Release is here: https://hackage.haskell.org/package/filepath-1.4.100.0
Demonstration about unsoundness of base with exotic encodings and how the new API fixes them is here: https://gist.github.com/hasufell/c600d318bdbe010a7841cc351c835f92
Migrations
Migrations can happen once the filepath, unix and Win32 packages are updated and in sync. A migration would usually involve using the new types from System.OsPath and the new API variants from unix/Win32.
When writing low-level cross platform code manually (shouldn't generally be necessary), the usual strategy is this:
#if defined(mingw32_HOST_OS) || defined(__MINGW32__)
import qualified System.OsPath.Data.ByteString.Short.Word16 as SBS
import qualified System.OsPath.Windows as PFP
#else
import qualified System.OsPath.Data.ByteString.Short as SBS
import qualified System.OsPath.Posix as PFP
#endif
crossPlatformFunction :: OsPath -> IO ()
#if defined(mingw32_HOST_OS) || defined(__MINGW32__)
crossPlatformFunction (OsString pfp@(WS ba)) = do
-- use filepath functions for windows specific operating system strings
let ext = PFP.takeExtension pfp
-- operate directly on the underlying bytestring (which is a wide character bytestring, so uses Word16)
let foo = SBS.takeWhile
...
#else
crossPlatformFunction (OsString pfp@(PS ba)) = do
-- use filepath functions for posix specific operating system strings
let ext = PFP.takeExtension pfp
-- operate directly on the underlying bytestring (which is just Word8 bytestring)
let foo = SBS.takeWhile
...
#endifPlatform specific code can be written using PosixPath/WindowsPath types.
If you have further questions, please let me know. I'm going to write a blog post outlining the affairs and more in-depth intro and migration strategies close after the release. This is a heads up.