safe vs. unsafe (Was: Haskell Platform proposal: Add the vector package)
nominolo at googlemail.com
Thu Jul 12 20:21:19 CEST 2012
I'm still very confused about this Safe Haskell business. I read
through the responses and it seems like there are several definitions
and of what is meant by safe/unsafe. Is there a document describing
this thoroughly? In particular I am interested in:
- What definition of "safe" are we using and how can other
definitions be incorporated? As I understand it, "safe" currently
means "does not subvert the type system". This excludes everything
based on the FFI, or any of the unsafe* primitives (and therefore
anything IO). Obviously, that would put a "safe" Haskell into the
"glorified calculator/useless" department.
- So I assume that "trusting" is the way to say, that an code
written on top unsafe primitives is indeed safe. How does that work?
Who decides whether something is trustworthy? Looking at , the
module is marked trustworthy. Shouldn't there be some sort of signing
or some sort of associated authority with the trust. Just because
someone declares his/her own module as trustworthy doesn't mean *I*
consider it trustworthy. But I might say, that I trust a package if
Johan or Bryan decided it's trustworthy. And even if it's the GHC team
declares something as trustworthy, doesn't mean that I want to
consider the module trustworthy for my particular use case.
- How intrusive is this system? As Johan points out, it doesn't seem
to be an opt-in extension, but has to be considered by package authors
whether they want to or not. The other concern that Johan pointed out
is how much does it violate abstraction? If the package author changes
the implementation (e.g., use the FFI), does that require an API
change? Obviously, it affects trust, but I don't see a way around
So, is there a document that discusses this?
On 12 July 2012 08:39, Bas van Dijk <v.dijk.bas at gmail.com> wrote:
> On 12 July 2012 05:52, Johan Tibell <johan.tibell at gmail.com> wrote:
>> It's unsafe in the sense that any module containing it cannot be
>> marked as Safe (only Trustworthy) and thus won't fit the scheme with
>> modules containing only Safe functions that Simon described.
> I think what Simon described was the current situation in the base
> library where we have:
> * .Unsafe modules marked as Unsafe that export an API which should be
> considered unsafe.
> * .Safe modules that export a safe API. These modules don't
> necessarily need to be marked as Safe (most of them can't because they
> themselves import unsafe modules, as in your Data.ByteString example)
> but they do need to be Trustworthy. Look at  for an example.
>  http://www.haskell.org/ghc/docs/latest/html/libraries/base-18.104.22.168/Control-Monad-ST-Safe.html
> Haskell-platform mailing list
> Haskell-platform at projects.haskell.org
Push the envelope. Watch it bend.
More information about the Libraries