
On Mon, Jul 16, 2012 at 01:25:11AM +0100, Thomas Schilling wrote:
On 16 July 2012 01:15, John Lato
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