On Tue, Oct 14, 2008 at 02:05:02PM +0100, Jules Bean wrote:
Mauricio wrote:
If I have a Haskell wrapper (with unsafe...) over a function that's never going to return different values and is always side-effect free, but can change depending on compile time options of its library; my program is running, and then the version of my library is updated by my distribution smart instalation system, which does update versions of libraries in use; is it possible that I get a wrong behavior of my program?
If you're talking aout an FFI function, the best option (in my opinion) would be to not import it in the IO monad, if possible. Which you couldn't do if it does something like allocate a C string... but in many cases this would be the cleanest approach.
I do not understand enough about package management to understand how running programs or libraries are updated, and less about how linking works between Haskelll and libraries on other languages, so I don't know if my program is guaranteed to stay with a single version of a library for each run.
(Sure this is a weird situation, but I do like to think about worst cases.)
In practice that is fine, with current RTSes and so on.
In principle it's not fine. A 'constant' should be constant over all time, not just constant over a particular library version or sub-version or a particular program invocation or OS or....
No, constants don't have to constant over all time. e.g. it's perfectly fine for compilers to implement System.Info, whose sole purpose to provide constants that are different in different library versions and OSs. http://haskell.org/ghc/docs/latest/html/libraries/base/System-Info.html#v:os
Who knows, maybe some future haskell runtime will be able to perform the trickery you describe and will cause this to break ;)
No, that sort of trickery breaks referential transparency, and itself is unsafe. It is in fact safe to assume that the RTS will never break referential transparency. David