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

newer
Proposal: add an order-reversing...

John Lato

15 Jul 2012 15 Jul '12

8:15 p.m.

On Sat, Jul 14, 2012 at 3:16 AM, Henning Thielemann < lemming@henning-thielemann.de> wrote:

...
On Fri, 13 Jul 2012, Brandon Allbery wrote:

And now I'm having a "so what's the point?" moment? All this effort so

...
we can just mark random stuff as Trusted anyway?

Today we have 'unsafePerformIO'. So if we praise the merits of Haskell's strong type system and then mention 'unsafePerformIO' the audience will ask "so what's the point of type safety then?" Well, the point is that unsafePerformIO is strongly discouraged and every use of it should be considered carefully.

We've just been told *not* to consider carefully for purposes of marking a module as Trustworthy; an argument based on considering carefully is not relevant.

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. John L.

Show replies by date

Thomas Schilling

15 Jul 15 Jul

8:25 p.m.

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

On 16 July 2012 01:15, John Lato wrote:

...

...
On Sat, Jul 14, 2012 at 3:16 AM, Henning Thielemann < lemming@henning-thielemann.de> wrote:

...
On Fri, 13 Jul 2012, Brandon Allbery wrote:

And now I'm having a "so what's the point?" moment? All this effort so

...
we can just mark random stuff as Trusted anyway?

Today we have 'unsafePerformIO'. So if we praise the merits of Haskell's strong type system and then mention 'unsafePerformIO' the audience will ask "so what's the point of type safety then?" Well, the point is that unsafePerformIO is strongly discouraged and every use of it should be considered carefully.

We've just been told *not* to consider carefully for purposes of marking a module as Trustworthy; an argument based on considering carefully is not relevant.

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". "Trustworthy" means "This module uses unsafe features but in a safe way", while "Unsafe" says "Some functions in this module are unsafe". That's the issue with vector. It exports a mostly-safe API, but also throws in a few unsafe functions, thus every use of the API must be audited for safety and be marked Trustworthy (or Unsafe, otherwise). Since SH works per-module, it can't detect that an "import Data.Vector hiding (unsafeIndex, ...)" is in fact safe. / Thomas

Ian Lynagh

8:54 p.m.

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

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

John Lato

9:05 p.m.

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

On Mon, Jul 16, 2012 at 8:25 AM, Thomas Schilling wrote:

...

On 16 July 2012 01:15, John Lato wrote:

...
...
On Sat, Jul 14, 2012 at 3:16 AM, Henning Thielemann < lemming@henning-thielemann.de> wrote:

...
On Fri, 13 Jul 2012, Brandon Allbery wrote:

And now I'm having a "so what's the point?" moment? All this effort so

...
we can just mark random stuff as Trusted anyway?

Today we have 'unsafePerformIO'. So if we praise the merits of Haskell's strong type system and then mention 'unsafePerformIO' the audience will ask "so what's the point of type safety then?" Well, the point is that unsafePerformIO is strongly discouraged and every use of it should be considered carefully.

We've just been told *not* to consider carefully for purposes of marking a module as Trustworthy; an argument based on considering carefully is not relevant.

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". "Trustworthy" means "This module uses unsafe features but in a safe way", while "Unsafe" says "Some functions in this module are unsafe". That's the issue with vector. It exports a mostly-safe API, but also throws in a few unsafe functions, thus every use of the API must be audited for safety and be marked Trustworthy (or Unsafe, otherwise). Since SH works per-module, it can't detect that an "import Data.Vector hiding (unsafeIndex, ...)" is in fact safe.

Yes, of course this is correct. I was just in the context of "save vs. unsafe-used-in-safe-way". But I think my point still stands, which is that the "considering carefully" (of whether or not code should be considered for inclusion in a project) is meant to be done by the code consumer, not the code author (who presumably has also considered carefully about how the API is meant to be used, functions that are meant to be safe vs those that have not, and many other issues). John

4692

Age (days ago)

4692

Last active (days ago)

List overview

Download

3 comments

3 participants

participants (3)

Ian Lynagh
John Lato
Thomas Schilling