[Haskell-cafe] Idea for hackage feature

[Ben Millwood]

On Fri, Sep 17, 2010 at 1:44 AM, Ivan Lazar Miljenovic
<ivan.miljenovic at gmail.com> wrote:
> 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.