Haskell Platform proposal: Add the vector package

Gábor Lehel illissius at gmail.com
Mon Jul 16 14:18:21 CEST 2012


On Mon, Jul 16, 2012 at 1:44 PM, Simon Marlow <marlowsd at gmail.com> wrote:
> On 16/07/2012 11:01, Roman Leshchinskiy wrote:
>>
>> Thomas Schilling wrote:
>>>
>>> To be fair, regardless of SH, I'd consider it good API design to put
>>> unsafe things into a separate module.
>>
>>
>> I'll ask again: why is putting unsafe* functions into a separate module
>> preferable to just following the unsafe* naming convention? I'm honestly
>> interested in an answer - it seems to me that for someone who doesn't want
>> to use unsafe functions, the two approaches are essentially equivalent and
>> for someone who does, a separate module is more cumbersome.
>
>
> Well, for one thing you can tell whether a module has access to unsafe stuff
> by just looking at its imports.  This argument applies both to users (it's
> clearer when things are separated by module) and to the implementation (we
> don't have to maintain a per-identifier safe flag, which would complicate
> the implementation and bloat interface files).
>
> The real problem here seems to be the clash between the meaning of "unsafe"
> in the context of Vector, and the meaning of "unsafe" in Safe Haskell.  I
> don't see a good way to resolve that conflict, though of course I think the
> definition of unsafe in Safe Haskell is sensible and I'd like that to become
> the accepted meaning of the term.  So far in Haskell there has been no
> consistent definition of unsafe, which is confusing for users.
>
> Just to repeat what I said earlier, I don't see there being any objection to
> putting unsafeRead with the other unsafe functions in vector, even though
> technically it is safe.

With apologies for repeating myself, isn't the fact that unsafeRead
and unsafeWrite can access arbitrary memory locations a problem? Does
memory safety not matter? Shouldn't it be represented at some level? I
recognize that if we consider them unsafe, that it means that FFI code
that deals with pointers would all have to be Trustworthy or Unsafe,
but I'm not sure that's a bad thing. Heck, with a raw pointer (or
unchecked array access) you could use it to write into GHC's heap and
change the contents of some immutable object, thereby violating
referential transparency, which is what Safe Haskell is supposed to
prevent, that is if you don't just crash the program outright.

-- 
Your ship was caught in a monadic eruption.



More information about the Libraries mailing list