System.Win32.Types to base library?
I am working on some Windows specific code for GHC in the base library. System.Win32.Types contains basic Win32 types and error handling functions. Using them would mean a dependency on the Win32 library. I could duplicate parts of System.Win32.Types that i need, but is it not preferable to relocate System.Win32.Types to the base library? Regards, Felix
Hello Felix, Monday, October 22, 2007, 9:52:35 PM, you wrote:
I am working on some Windows specific code for GHC in the base library. System.Win32.Types contains basic Win32 types and error handling functions. Using them would mean a dependency on the Win32 library. I could duplicate parts of System.Win32.Types that i need, but is it not preferable to relocate System.Win32.Types to the base library?
NO, because this will lead again to non-upgradability hell. other libraries will need to import these types from different places depending on GHC version where they are runned -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
NO, because this will lead again to non-upgradability hell. other libraries will need to import these types from different places depending on GHC version where they are runned
Ok, so how about a new module in base for Windows API error handling? E.g. a Foreign.C.Error.Win32 module which resembles Foreign.C.Error.
Felix Martini wrote:
I am working on some Windows specific code for GHC in the base library. System.Win32.Types contains basic Win32 types and error handling functions. Using them would mean a dependency on the Win32 library. I could duplicate parts of System.Win32.Types that i need, but is it not preferable to relocate System.Win32.Types to the base library?
You don't say what you're working on specifically, but in general the direction we want to move in is to develop new stuff outside of the base package, where you have full access to the Win32 or unix APIs. In the upcoming GHC release we've separated out various parts of base for this reason. Cheers, Simon
2007/10/23, Simon Marlow:
You don't say what you're working on specifically, but in general the direction we want to move in is to develop new stuff outside of the base package, where you have full access to the Win32 or unix APIs. In the upcoming GHC release we've separated out various parts of base for this reason.
I'm working on overlapped IO support for Haskell handles (sockets in particular) using an IO completion port. I'll put the code in a separate library. Regards, Felix
Felix Martini wrote:
2007/10/23, Simon Marlow:
You don't say what you're working on specifically, but in general the direction we want to move in is to develop new stuff outside of the base package, where you have full access to the Win32 or unix APIs. In the upcoming GHC release we've separated out various parts of base for this reason.
I'm working on overlapped IO support for Haskell handles (sockets in particular) using an IO completion port. I'll put the code in a separate library.
ooh, that would be nice. I imagine it won't be possible to put it in a separate library and have it work nicely with the existing Handle implementation; you really want it to replace the existing low-level IO for Handles. If you could integrate it with the existing IO manager thread in GHC.Conc, then all the better. In that case I suggest the best option for now is to pull in as much Win32 support as you need, in a similar way to System.Posix.Internals which has the POSIX bits that the base package needs to know about. Cheers, Simon
Hello Felix, Tuesday, October 23, 2007, 7:22:19 PM, you wrote:
I'm working on overlapped IO support for Haskell handles (sockets in particular) using an IO completion port. I'll put the code in a separate library.
imho, it's better to put it into separate library. consider also an option to provide it as extension to the my Streams library ( http://haskell.org/haskellwiki/Library/Streams ) long time there was discussion about making universal API to the various overlapped IO interfaces (epoll, kqueue..), i think that Win32 support may be a part of this. unfortunately, we lack enough level of interest to complete the new I/O library development, although there is significant interest from some developers -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Bulat Ziganshin wrote:
Tuesday, October 23, 2007, 7:22:19 PM, you wrote:
I'm working on overlapped IO support for Haskell handles (sockets in particular) using an IO completion port. I'll put the code in a separate library.
imho, it's better to put it into separate library. consider also an option to provide it as extension to the my Streams library ( http://haskell.org/haskellwiki/Library/Streams )
Sure, but that would preclude using overlapped IO in the standard Handle implementation, which is where we need it right now. You want to be able to do ByteString IO using overlapped IO underneath, for example. I'm not claiming this is a good long-term plan, but in order for it to be useful *now*, it has to go into base. Cheers, Simon
Hello Simon, Thursday, October 25, 2007, 2:19:41 PM, you wrote:
imho, it's better to put it into separate library. consider also an option to provide it as extension to the my Streams library ( http://haskell.org/haskellwiki/Library/Streams )
Sure, but that would preclude using overlapped IO in the standard Handle implementation, which is where we need it right now. You want to be able to do ByteString IO using overlapped IO underneath, for example.
I'm not claiming this is a good long-term plan, but in order for it to be useful *now*, it has to go into base.
it's interesting that my understanding of situation is directly opposite - anything implemented just now in terms of base cannot be used next 1-1.5 years (many people skip x.x.0 GHC releases), while implemented as separate library van be used immediately ByteString support isn't problem for Streams, although it needs to be implemented. i've done this in 0.2 version, but it is completely bitrotted now and i don't have time to work on it but i propose to at least discuss architecture of future IO libraries - hope that all interested people have enough time and interest at least for doing this -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On Mon, Oct 22, 2007 at 07:52:35PM +0200, Felix Martini wrote:
I am working on some Windows specific code for GHC in the base library. System.Win32.Types contains basic Win32 types and error handling functions. Using them would mean a dependency on the Win32 library. I could duplicate parts of System.Win32.Types that i need, but is it not preferable to relocate System.Win32.Types to the base library?
This won't help you right now, but FYI the long term plan is to split the base package up to the extent that Win32 can be underneath most of base rather than on top of it. Thanks Ian
Hello Ian, Tuesday, October 23, 2007, 9:02:57 PM, you wrote:
This won't help you right now, but FYI the long term plan is to split the base package up to the extent that Win32 can be underneath most of base rather than on top of it.
the Handle type is used in the IOException type which is used in IO type definition and Prelude.catch. so it will be hard to move Handle definition outside of GHC/IOBase module -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Bulat Ziganshin wrote:
Tuesday, October 23, 2007, 9:02:57 PM, you wrote:
This won't help you right now, but FYI the long term plan is to split the base package up to the extent that Win32 can be underneath most of base rather than on top of it.
the Handle type is used in the IOException type which is used in IO type definition and Prelude.catch. so it will be hard to move Handle definition outside of GHC/IOBase module
Ultimately, the whole IO library needs to be separated. I think a prerequisite for this will be to do extensible exceptions, because the reason that everything is so tightly coupled at the moment is because the Monad instance for IO refers to Exception, and Exception refers to Handle, as you say. With extensible exceptions we can break this dependency. Cheers, Simon
Hello Simon, Thursday, October 25, 2007, 2:15:05 PM, you wrote:
Ultimately, the whole IO library needs to be separated. I think a prerequisite for this will be to do extensible exceptions, because the reason that everything is so tightly coupled at the moment is because the Monad instance for IO refers to Exception, and Exception refers to Handle, as you say. With extensible exceptions we can break this dependency.
yes, my thought was exactly the same. this plan looks real. i propose to return to debating it when GHC team will have time, under the "further split of Base" title -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
participants (4)
-
Bulat Ziganshin -
Felix Martini -
Ian Lynagh -
Simon Marlow