Tue, 02 Jan 2001 19:40:11 +1100, Manuel M. T. Chakravarty <chak@cse.unsw.edu.au> pisze:
PS: It could be argued that `Ptr ()' can always be used instead of `Addr' and that therefore we should do away with `Addr' altogether. Opinions?
I agree that Addr uses should be replaced by Ptr and FunPtr (well, I thought it was obvious!). Since Addr is used much in ghc and nhc and probably external libraries, we will live with both for some time, perhaps long, and it's not necessary to convert everything in a hurry. But I would not care if some functionality is provided in Ptr flavor only, especially as it's easy to convert in both directions. newForeignObj has been converted to Ptr, but since ForeignObjs themselves were later replaced with ForeignPtrs, it makes sense to let newForeignObj use Addr again as in previous released versions of ghc. For withForeignObj it could be done for consistency too (it's new so it does not really matter). I would let freeHaskellFunPtr accept and ignore nullFunPtr, since I once had to write when (ptr /= nullFunPtr) $ freeHaskellFunPtr ptr and it can be seen as consistent with free. It could be called freeHsFunPtr instead. I asked once and got no response: in ghc's implementation, should it really be foreign imported unsafe? On IA-64 C function pointers are AFAIK twice as big as data pointers (16 bytes!), to hold a global data pointer associated with the module the function came from, which is a part of a model of dynamically linked libraries. I don't know what ghc is going to do with it - it uses function pointers internally a lot! It also means that FunPtr will no longer be represented the same as Ptr on IA-64. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK