safe vs. unsafe (Was: Haskell Platform proposal: Add the vector package)

[Simon Marlow]

Hi Thomas,

All these questions are answered by the Haskell Symposium paper, which 
we'll post very shortly. FYI, the FFI is mostly safe, as long as you 
declare foreign imports to have an IO result type (otherwise it's 
unsafePerformIO, and hence unsafe).  Unsafety is not viral: as soon as 
you have a safe API, you can declare its implementation to be 
Trustworthy, and then it is usable from safe code.

Cheers,
	Simon

On 12/07/12 19:21, Thomas Schilling wrote:
> 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 [1], 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
> that.
>
> So, is there a document that discusses this?
>
> [1]: http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.5.1.0/Control-Monad-ST-Safe.html
>
> 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 [1] for an example.
>>
>> Bas
>>
>> [1] http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.5.1.0/Control-Monad-ST-Safe.html
>>
>> _______________________________________________
>> Haskell-platform mailing list
>> Haskell-platform at projects.haskell.org
>> http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
>
>
>