The `base` package plans to drop certain GHC-specific functionality

[mpilgrem]

See:

• Switch to using Win32 for obtaining Windows handles #185
• Fix #185 Don't depend on GHC.IO.* from base, from GHC 9.10 #186
• Re #186 Revert "Fix #185 Don't depend on GHC.IO.* from base, from GHC 9.10" #189
• Switch to the new operations for obtaining OS handles #187

See also, for context:

• table: base modules stability
• affected packages analysis
• GHC MR: Add operations for obtaining operating-system handles

[mpilgrem]

@jeltsch, your original plan (#185, now overtaken by #187) was to use the Win32 package's:

withHandleToHANDLE :: Handle -> (HANDLE -> IO a) -> IO a

The withHandleToHANDLE code came from this library. The history is: it started here, was copied by Win32, this library then dropped the original for Win32's copy, and then this library brought a copy of the code back home when Win32 adopted filepath as a dependency (to avoid circular dependencies).

As the Win32 code itself uses GHC.IO.Handle.Types from the base package, I think the Win32 package is going to need a solution to the same problem. (Cc-ing @bgamari, for info.)

[jeltsch]

@mpilgrem, maybe better use the URL https://gitlab.haskell.org/jeltsch/ghc-module-data/-/blob/master/Hackage%20uses%20of%20modules%20that%20should%20be%20internal/Stability%20risk%C2%A03/by%20module%20and%20using%20package.md for the link to the affected-packages analysis, as this URL doesn’t fix a certain commit containing this documentation. The affected-packages analysis is done, but there still may be small fixes made to this documentation of the results.

[jeltsch]

By the way, there is now an evolving file that contains the above-mentioned documentation in more processed form along with information about solutions.

[jeltsch]

As the Win32 code itself uses GHC.IO.Handle.Types from the base package, I think the Win32 package is going to need a solution to the same problem. (Cc-ing @bgamari, for info.)

Thanks for pointing this out.

We already have the Win32 library on our radar (see the above-mentioned documents for the details). That said, the situation with Win32 is a bit better: Win32 is a boot library and thus pretty much tied to GHC already, so that it might be acceptable to have it depend on ghc-internal, something that we recommend against in general.