As I didn't catch the whole thread, I hope I'm not just repeating everyone else: Roel van Dijk wrote:

I guess what unsafe should mean is a matter of taste. Personally I find correctness more important that pureness. An unsafe function will crash your program if evaluated when its preconditions do not hold. Whether that is because of impurity (segmentation fault?), a partial pattern match or a direct error "bla" is not that important. It might be important when determining why your program crashed, but the result is still the same.

Maybe for the purposes of naming functions it's sufficient to argument that a crash is a crash whatsoever, but as for terminology in general, I think it's good to distinguish (1) partial functions from (2) functions that break purity, may lead to segmentation faults etc. I suppose (2) is the »traditional« meaning of unsafe. The motivation for this distinction is that you can still reason to some extent about (1) if you consider _|_, and that there are many functions that, although useful and correct, aren't guaranteed to terminate on infinite input, thus are partial. On the other hand, functions from (2) should always be called unsafeFoo, and/or wrapped by safe functions. Kalman