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

15 Jul 2012


      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