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

Ian Lynagh igloo at earth.li
Mon Jul 16 02:54:20 CEST 2012


On Mon, Jul 16, 2012 at 01:25:11AM +0100, Thomas Schilling wrote:
> On 16 July 2012 01:15, John Lato <jwlato at gmail.com> wrote:
> >
> > I think the idea here is that, as a package author, it's okay to just
> > throw Trustworthy anywhere ghc can't infer Safe on its own.  As a
> > package user, if you care about Safe Haskell, it's your responsibility
> > to audit/consider carefully to determine if Trustworthy code is
> > something you're willing to include in your codebase.
> 
> No, not quite.  If your module exports a function like "unsafeIndex"
> or similar you must mark your module as "Unsafe" and definitely *not*
> as "Trustworthy".

The point is, you can mark unsafe things as trustworthy if you like, and
the system doesn't break. It's up to the end user whether they mark the
package as trusted or not, and thus whether the modules that you claim
are "trustworthy" should be treated as safe.

I'm not convinced that the trustworthy pragma is the right design
choice, though. I believe the idea is that a single package can export
    Foo.Safe, Foo.Trustworthy,
    Foo.Unsafe, Foo.Internals
and a package-level trust flag is sufficient, provided you agree with
the author about what is and isn't trustworthy, to allow access to all
the safe/trustworthy stuff, but none of the unsafe internals. This is
certainly convenient when you agree.

But if you disagree that a module (or even a single function) marked
trustworthy is safe, then you have to disallow the entire package. And
if there is an additional module (or function) that you think is safe,
then you can't provide access to it. (to some extent you can work round
these issues by providing wrapper packages with your own pragmas, but as
well as being quite heavyweight, that doesn't really help you to allow
3rd party libraries to use the safe parts of another library).


Thanks
Ian




More information about the Libraries mailing list