Switch to using Win32 for obtaining Windows handles

[jeltsch]

There is an effort to move some GHC-specific modules out of base. A candidate for such moving is GHC.IO.Handle.Types. This module is often used for obtaining operating-system handles (file descriptors, Windows handles) from Haskell handles. Such a use is also present in the ansi-terminal package: in the implementation of the internal operation System.Console.ANSI.Windows.Win32.Types.withHandleToHANDLE. However, this implementation was copied into the Win32 package already for its version 2.5.1, so that now ansi-terminal does not need its own implementation of Windows handle acquisition anymore.

This pull request removes the implementation of withHandleToHANDLE from System.Console.ANSI.Windows.Win32.Types and lets this module re-export withHandleToHANDLE from Win32 instead.

I suggest to check, as a follow-up project, whether System.Console.ANSI.Windows.Win32.Types is needed at all these days, given that the module System.Win32.Types from Win32 seems to provide pretty much the same things.

[mpilgrem]

@jeltsch, thanks for your pull request but ansi-terminal deliberately avoids a dependency on Win32. See:

• Separate System.Console.ANSI.Types to its own package #151 (comment)
• Avoid dependency on Win32 and, hence, filepath #158
• Fix #158 Eliminate dependency on Win32 package #159

If base is dropping this functionality, I guess it will have to be replicated in ansi-terminal itself.

Copying-in @Bodigrim for information, as his comment was the origin for dropping Win32.

[mpilgrem]

I see that base GHC.IO.Handle.Types is a re-export of ghc-internal GHC.Internal.IO.Handle.Types. So, I presume, ansi-terminal can just depend on ghc-internal directly.

@jeltsch, is GHC.IO.Handle.Types the only module affected? If not, are you able to provide me with a link that describes the wider scope of the coming changes?

[mpilgrem]

I have an alternative pull request (#186) with the same ultimate objective, so closing this one.

[jeltsch]

@jeltsch, is GHC.IO.Handle.Types the only module affected? If not, are you able to provide me with a link that describes the wider scope of the coming changes?

There is a table about the stability of base modules, on which this present work is based. At the moment, we’re dealing with those modules that have a “stability risk” of 3 according to this table. I have looked through all packages on Hackage that use any of these modules and checked what they are using them for. There is a document that shows the results of this investigation.

I’m happy to answer more questions in case something is unclear.

[jeltsch]

See #187 for an alternative solution, which avoids the Win32 dependency.