unsafeShift operations for Data.Bits

Donald Bruce Stewart dons at cse.unsw.edu.au
Thu Nov 9 21:00:03 EST 2006


john:
> On Mon, Nov 06, 2006 at 02:09:18PM -0500, Samuel Bronson wrote:
> > It isn't really *unsafe*, exactly. But it might not be purely
> > functional. However, it isn't imperative or anything like that. Also,
> > for rotate, I needed to change the implementations in the *libraries*
> > (it was only the GHC-specific implementations, though). (Also, nobody
> > seems to have applied that patch yet for some reason.) And I needed to
> > change them to use the raw, unchecked primops.
> > 
> > Oh, that reminds me. Why call them "unsafe"? Why not "unchecked" as
> > GHC's primops are called?
> 
> yes definitely. we should reserve 'unsafe' for when we really mean it.
> 
> I see three levels of unsafeness, and try to use them appropriately.
> 
> unsafeFoo - can break the static properties of the program. such as
> unsafePerformIO breaking typesafety, or the obvious unsafeCoerce

Good idea:

    unsafePerformIO
    unsafeCoerce#

> unwiseFoo - can break dynamic properties of the program, the program
> will not go wrong or see any inconsistant results within a single run,
> but it might see different ones if run again or on a different machine.

    unwiseInterleaveIO :)

> uncheckedFoo - under certain conditions that arn't checked for, this
> routine may produce well defined, but unspecified behavior. (as in, the
> behavior might depend on something compiler or architecture specific)

    uncheckedShift
    uncheckedRead/Write

-- Don


More information about the Libraries mailing list