On 30/08/2012 02:33, Johan Tibell wrote:
> Hi all,
>> After reading the Safe Haskell paper today, I got the impression that
> no one actually wants the .Safe modules currently in vector. If vector
> was to be made Safe Haskell friendly, we should instead add .Unsafe
> modules (and have the rest of the modules declared Trustworthy).
> Having .Unsafe modules is better than having .Safe modules, because
>> * there are many more safe functions than unsafe functions, and
> * Haskell is by default safe, so having modules called .Safe is a bit
> like having modules called .Pure. There's precedence for having
> .Unsafe modules in e.g. bytestring.
>> If that's the case, and if Roman agrees, I suggest we release a new
> major version that
>> * removes all the .Safe modules [1],
> * adds new .Unsafe modules, and
> * marks the functions that are now exported through the .Unsafe
> modules deprecated in their original (non-.Unsafe) location.
+1 from me, although when we discussed doing this previously Roman was
not keen.
> I suggest that the deprecation doesn't involve an actual deprecation
> pragma in this release [2], but instead just a comment. A future major
> release could add the deprecation pragma and another major release
> after that could remove the actual functions.
Why not a deprecation pragma initially? That's like adding another
level of "soft deprecation"; how long before we also need "extra-soft
deprecation" and "ultra-soft deprecation"? (I feel a bog-roll analogy
coming on :-)
> 1. Normally I would suggest a deprecation period before removing
> functions from an API, but I just searched through all of Hackage and
> there's only a single package (bitvec) that makes use of the .Safe API
We also have:
Data.Array.IO.Safe
Control.Monad.ST.Safe
Foreign.Marshal.Safe
and I think all of these are in the same state: the unsafe APIs in the
non-Safe modules are currently deprecated, and the .Safe modules can be
removed at some time in the future.
Cheers,
Simon