Add operations for obtaining operating-system handles

[jeltsch]

In order to decouple base versioning from GHC versioning, it is necessary to remove various GHC-specific modules from base. Among these module are GHC.IO.Handle.Types and GHC.IO.Handle.Internals. Currently, there are various packages on Hackage that use these modules. One purpose of such use is obtaining operating-system handles (file descriptors, Windows handles) that underlie Haskell handles.

GHC merge request !14732 adds a new module System.IO.OS to base, which contains several operations for obtaining operating-system handles. These new operations, together with the operation withHandleToHANDLE from the Win32 package, have been used to implement alternatives to operating-system handle acquisition based on the above-mentioned internal modules in a total of six packages on Hackage. For details, see the following respective pull requests:

• UnkindPartition/ansi-terminal#187
• haskell/haskeline#211
• jeltsch/hsshellscript#2
• haskell/process#348
• Happstack/sendfile#5
• biegunka/terminal-size#20

[hasufell]

Since I'm maintaining file-io I'd be interested in a PR/patch.

[jeltsch]

Is file-io affected by this? According to my data collection, file-io-0.1.5 has only the following uses of modules that should be internal and whose internalization carries stability risk 3, which includes GHC.IO.Handle.Types and GHC.IO.Handle.Internals:

GHC.IO.Handle.Internals

• Uses debugIO
  • Does so for automatic finalization of handles

GHC.IO.Handle.Types

• Uses Handle
  • Can be imported from System.IO
• Uses Handle’s data constructors
  • Does so for automatic finalization of handles
• Uses Handle__
  • Does so for automatic finalization of handles

GHC.IO.SubSystem

• Uses ioSubSystem in tests on Windows
  • Does so for selectively setting FILE_FLAG_OVERLAPPED
  • Can use (<!>) instead

[hasufell]

Well, you're saying that GHC.IO.Handle.Types and GHC.IO.Handle.Internals ought to be removed (although not in this proposal). So how do I future proof myself?

And what about GHC.IO.Handle.FD? Will it stay?

[jeltsch]

Well, you're saying that GHC.IO.Handle.Types and GHC.IO.Handle.Internals ought to be removed (although not in this proposal). So how do I future-proof myself?

The plan is to provide more higher-level operations beyond what this CLC proposal is about and to remove GHC.IO.Handle.Types and GHC.IO.Handle.Internals only once most of their uses have become superfluous because enough such operations have been added. Even then, the functionality of GHC.IO.Handle.Types and GHC.IO.Handle.Internals may still be provided by ghc-internal and therefore continue to be usable where absolutely needed.

Providing appropriate patches for file-io is not possible at this point, because the necessary high-level operations do not yet exist.

The scope of this CLC proposal is really only the addition of the operations for obtaining operating-system handles. I mentioned the planned removal of certain GHC-specific modules from base only to provide context for this proposal.

And what about GHC.IO.Handle.FD? Will it stay?

Likely it will, because it is marked as having stability risk 1 in the table on base module stability. The present removal plan is only about modules with stability risk 3.

[jeltsch]

This proposal has been around for quite some while. Is there anything left that should be addressed from my side? The corresponding merge request !14732 can be considered finalized by now.

[jeltsch]

Happy New Year, everyone. @hasufell, let me just send this friendly reminder that the merge request related to this proposal is ready. What would be the next steps regarding this proposal?

[hasufell]

Thanks, I want to take a closer look at the MR. I'm sorry for the delay.

[hasufell]

Dear CLC members, let's vote on the proposal to add operations for obtaining operating-system handles.

@parsonsmatt @velveteer @TeofilC @Daniel-Diaz @ChickenProp @noughtmare @mpscholten @doyougnu

---

+1

[TeofilC]

+1

[mpscholten]

+1

[doyougnu]

+1

[velveteer]

+1

[hasufell]

5 out of 9 votes is enough to approve, thanks all.