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....@gmail.com> wrote:
On 12 July 2012 05:52, Johan Tibell<johan.tib...@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@projects.haskell.org
http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
_______________________________________________
Haskell-platform mailing list
Haskell-platform@projects.haskell.org
http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
