This release implements support for the “abstract filepath proposal” (AFPP). There are no breaking changes in the existing API.
Hackage: https://hackage.haskell.org/package/filepath-1.4.100.0
More information can be found on my blog: https://hasufell.github.io/posts/2022-06-29-fixing-haskell-filepaths.html
Congratulations! This is great news!
This is great. This is the type of work the Haskell ecosystem really needs. Thanks for your work on this!
When can we expect to see the file-io library on hackage?
After unix and Win32 have had a release that includes support:
This is mainly blocked by the Win32 package.
Both unix and Win32 now have releases supporting the new API:
Done: file-io: Basic file IO operations via 'OsPath'
The last major outstanding package is directory. The maintainer said they will try to update it in time for GHC-9.6. Until then, refer to my branch https://github.com/hasufell/directory/tree/AFPP
The only other package I will migrate myself is hpath, which will then probably be the first strongly typed filepath library that uses OsPath under the hood (current WIP branch is here).
That will be it from my side. Anything else is up to the community to do.
If anyone wants to get this into base (at least the type), you have my support. But I won’t drive that myself.
The ChangeLog for directory-1.3.8.0 explains:
Modules in
directoryare no longer considered Safe because theSystem.OsPathdependency is no longer Safe.
Packages like fast-logger-3.1.1 that depend on directory being ‘safe’ will no longer build with directory >= 1.3.8.0.
I don’t understand fully ‘Safe Haskell’. Could you explain why, with AFPP, things are ‘unsafe’ that were previously ‘safe’?
(EDIT: my reason for asking is that I was exploring what it would take to adopt AFPP with Stack, and fast-logger not building is a sticking point.)
Not sure anyone does. We can mark those modules as Trustworthy though. But I don’t know what any of that really means.
I see. System.OsPath.MODULE_NAME.Internal.fromString makes use of unsafePerformIO, and so System.OsPath cannot be ‘Safe Haskell’ but it can be declared by its authors to be Trustworthy.
If the authors can properly make that declaration, then it seems to me that some users of filepath may find it useful.
Edit: I’ve added ‘properly’ in the light of the subsequent comments, to clarify my intended meaning.
Could these unnamed users explain how they benefit from Safe (aka unverified code with unsafePerformIO hidden under Trustworthy) Haskell first? I think we all will be much better to stop participating in this safety circus.
Here is a recent example: Data.Array.Byte. The code was ported from Data.Primitive.ByteArray, so it should be as Trustworthy as possible. I originally opposed to marking it as such, but was persuaded otherwise on the grounds that there is literally nothing unsafe you can do with the API provided, because, well, there is no API, right? And that’s how it got released.
stimes i arr
| itgr < 1 = emptyByteArray
| itgr <= (fromIntegral (maxBound :: Int)) = replicateByteArray (fromIntegral itgr) arr
| otherwise = error "Data.Array.Byte#stimes: cannot allocate the requested amount of memory"
where itgr = toInteger i :: Integer
The truth is that the code as written is gullible to integer overflow. Carefully chosen offsets allow any of your dependencies to modify memory of the main program, which defeats the very purpose of Safe Haskell.
Since that mishap I insist that code can be marked as Trustworthy only if it was formally verified.
…as alluded to by the documentation for copyByteArray:
-- Note: this function does not do bounds or overlap checking.
something which the advocates for stimes (somehow) failed to notice. As for it’s formal verification:
it would appear to be needed where copyByteArray is being used, analogous to errantly using 0 with div - perhaps when we all have quantum computers at our disposal…