Integrating OsPath APIs in effectful

[Kleidukos]

@arybczak I have been prototyping with having OsPath-base APIs in Effectful. Today we have the following:

• Effectful.FileSystem
  • Effectful.FileSystem.IO
    • Effectful.FileSystem.IO.ByteString
      • Effectful.FileSystem.IO.ByteString.Builder
      • Effectful.FileSystem.IO.ByteString.Lazy
    • Effectful.FileSystem.IO.File

My first attempt was to add *.OsPath modules, giving us:

• Effectful.FileSystem
  • Effectful.FileSystem.OsPath
  • Effectful.FileSystem.IO
  • Effectful.FileSystem.OsPath
    • Effectful.FileSystem.IO.ByteString
      • Effectful.FileSystem.IO.ByteString.OsPath
      • Effectful.FileSystem.IO.ByteString.Builder
      • Effectful.FileSystem.IO.ByteString.Lazy
        • Effectful.FileSystem.IO.ByteString.Lazy.OsPath
    • Effectful.FileSystem.IO.File
      • Effectful.FileSystem.IO.File.OsPath

From what I understand, we have two dimensions that determine the amount of APIs:

• Does the API take a FilePath or an OsString?
• Does the API return a StrictByteString or a LazyByteString?

There is probably the opportunity to bundle some of these modules together? I'm having a hard time understanding why the .IO.File module does not have actions on file like removeFile, for instance.

In particular I'd like to challenge the existence of the .IO module hierarchy, since there the effect is static and thus cannot have a pure interpreter.

If you're down with it I can make suggestions to redesign the module hierarchy so that we have alternative APIs that don't duplicate that many modules.

[arybczak]

In particular I'd like to challenge the existence of the .IO module hierarchy

AFAIR the existing hierarchy is a copy of the hierarchy from unliftio. Major reorganization might not be worth it, given that some sort of backwards compatibility deprecation period would be needed.