RE: unsafePerformIO and unsafeInterleaveIO
qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) wrote,
Mon, 19 Mar 2001 11:04:43 -0700, Alastair Reid <reid@cs.utah.edu> pisze:
Should these functions be available through the standard FFI? IMHO they should.
I don't understand the question. Are you asking which modules should export them?
Yes. IMHO they should be made as "standard" as the rest of FFI and exported from module Foreign.
I guess, you could a (maybe inefficient) version of unsafePerformIO using the FFI functionality anyway. This gives us a default implementation, so I thing, we should include it. I am not so sure about unsafeInterleaveIO.
I'm not sure about including these functions in Foreign. Their location should be standardised, sure: but that's something to be discussed as part of the new library proposal. I don't feel they belong in Foreign. Cheers, Simon
On Tue, 20 Mar 2001, Simon Marlow wrote:
I'm not sure about including these functions in Foreign. Their location should be standardised, sure: but that's something to be discussed as part of the new library proposal. I don't feel they belong in Foreign.
So they can be provided somewhere else and exported by Foreign as well. -- Marcin 'Qrczak' Kowalczyk
"Simon Marlow" <simonmar@microsoft.com> wrote,
qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) wrote,
Mon, 19 Mar 2001 11:04:43 -0700, Alastair Reid <reid@cs.utah.edu> pisze:
Should these functions be available through the standard FFI? IMHO they should. [..] I guess, you could a (maybe inefficient) version of unsafePerformIO using the FFI functionality anyway. This gives us a default implementation, so I thing, we should include it. I am not so sure about unsafeInterleaveIO.
I'm not sure about including these functions in Foreign. Their location should be standardised, sure: but that's something to be discussed as part of the new library proposal. I don't feel they belong in Foreign.
I guess, the point is that FFI routines often need unsafePerformIO - for example, to implement the marshalling for pure external functions. Without a standard way to get at unsafePerformIO, such code would still rely on non-standard features, which goers against the aim of standardising the rest of the FFI. Manuel
Without a standard way to get at unsafePerformIO, such code would still rely on non-standard features, which goers against the aim of standardising the rest of the FFI.
The Hugs-GHC standard libs have them exported from IOExts. Of course, the Hugs-GHC standard isn't an official Haskell library committee approved standard but, since it's something like 4 years old, I think it's a better candidate for approval than the ffi library which hasn't really stabilised yet, hasn't been whacked on by a large number of users, is much younger, etc. A
"Alastair Reid" <reid@cs.utah.edu> wrote,
Without a standard way to get at unsafePerformIO, such code would still rely on non-standard features, which goers against the aim of standardising the rest of the FFI.
The Hugs-GHC standard libs have them exported from IOExts.
Of course, the Hugs-GHC standard isn't an official Haskell library committee approved standard but, since it's something like 4 years old, I think it's a better candidate for approval than the ffi library which hasn't really stabilised yet, hasn't been whacked on by a large number of users, is much younger, etc.
There is only one flaw: It doesn't work with nhc98. I'd really prefer to keep the FFI stuff self-contained and have it work on ghc, Hugs, *and* nhc. Cheers, Manuel
Alastair:
The Hugs-GHC standard libs have them exported from IOExts.
Manuel:
There is only one flaw: It doesn't work with nhc98.
Huh? I thought nhc provided a reasonable subset of the Hugs-GHC libraries and, since the IO extensions are one of the first extensions people ask for, I assumed that if they provided anything they would certainly provide them. So does nhc provide them but under a different name or through a different module? Could nhc not just add them to IOExts in their next distribution? Alastair
I thought nhc provided a reasonable subset of the Hugs-GHC libraries and, since the IO extensions are one of the first extensions people ask for, I assumed that if they provided anything they would certainly provide them.
Yes, nhc98 provides most of the popular IO extension functions, including unsafePerformIO.
So does nhc provide them but under a different name or through a different module?
nhc98 has the module IOExtras instead of IOExts. Also hbc for instance has similar facilities in modules called UnsafePerformIO, UnsafeDirty, IOMutVar, and NonStdTrace, and what's more, I think they may well all pre-date the Ghc implementations. I chose the name IOExtras for nhc98 as a partial concession toward the Ghc library IOExts, but I'm afraid I just couldn't bring myself to go the whole way and use the fully-cryptic name. :-) I would also want to echo Simon's comment that the new hierarchical namespace and library proposal should go a long way to making the library situation better in the very near future. We are currently discussing a general layout and re-naming of the existing modules from hslibs. If Hugs users and developers don't join in the discussion, then we could be wasting our effort. We really want to develop a de-facto cross-compiler standard, not just a one-compiler or two-compiler standard.
Could nhc not just add them to IOExts in their next distribution?
I will continue to resist horrible names. In any case, IOExts will soon be split up and renamed into separate libraries something like System.IO Data.IORef Structure.Array.IO The exact scheme is still wide open for discussion. Regards, Malcolm
participants (5)
-
Alastair Reid -
malcolm-ffi＠cs.york.ac.uk -
Manuel M. T. Chakravarty -
Marcin 'Qrczak' Kowalczyk -
Simon Marlow