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

John Lato jwlato at gmail.com
Mon Jul 16 03:05:22 CEST 2012


On Mon, Jul 16, 2012 at 8:25 AM, Thomas Schilling
<nominolo at googlemail.com> wrote:
> On 16 July 2012 01:15, John Lato <jwlato at gmail.com> wrote:
>>> On Sat, Jul 14, 2012 at 3:16 AM, Henning Thielemann <
>>> lemming at 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



More information about the Libraries mailing list