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