[Haskell-cafe] Linking and unsafePerformIO

David Roundy droundy at darcs.net
Tue Oct 14 09:49:06 EDT 2008

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.


> 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.


More information about the Haskell-Cafe mailing list