On Fri, Sep 17, 2010 at 1:44 AM, Ivan Lazar Miljenovic
On 17 September 2010 03:18, Henning Thielemann
My suggestion is to move the Unsafe modules to a new package 'unsafe'. Then you can easily spot all "dirty" packages by looking at reverse dependencies of 'unsafe'.
Hooray, yet another supposedly stand-alone library that GHC will depend on and thus can't be upgraded anyway, so there's no real advantage of making it stand-alone (after all, doesn't base use unsafeInterleaveIO or something for lazy IO?).
Well, it's not like we plan on regularly fiddling that API :) The clever thing about this suggestion is that most packages don't *export* equivalent power to unsafePerformIO even if they import it (inlinePerformIO from bytestring is a notable exception) so you can easily see from a library's *immediate* dependencies whether it could potentially do anything naughty or not. Also, it's implementable entirely with existing technology, although we'll probably want a major base version bump to remove the modules. When discussing this sort of "taint" I think it's important not to forget that the FFI can be just as bad. For a start, one common use of unsafe functions is to provide a pure API to a foreign library (as is done in RWH), and clearly in such cases the proof of correctness cannot exist in the language because it depends on properties of libraries, which may not even be linked until runtime. Secondly, FFI imports are almost as bad safetywise as System.IO.Unsafe, and twice as impossible to prove correct. So your taint measure should take into account use of that extension, too.