Haskell Platform proposal: Add the vector package

[Roman Leshchinskiy]

Simon Marlow wrote:
> On 18/06/2012 23:06, Roman Leshchinskiy wrote:
>> On 18/06/2012, at 19:39, Johan Tibell wrote:
>>
>>> On Mon, Jun 18, 2012 at 9:54 AM, Bas van Dijk <v.dijk.bas at gmail.com>
>>> wrote:
>>>> I like the idea of the vector-safe package. Are you also proposing to
>>>> add this package to the HP? (I would also be +1 on that)
>>>
>>> I think it makes sense as a separate package, but I don't think it
>>> makes sense to add to the HP. SafeHaskell isn't used enough to warrant
>>> that.
>>
>> I fully agree with Johan and I wouldn't even really want to maintain
>> this separate package. It is a lot of work for something I don't use
>> and don't entirely understand. The *.Safe modules in vector are
>> currently bitrotted since I forget to update them when I add new
>> operations and I'm not really sure what is and isn't "safe" anyway.
>> Is anybody interested in this code at all?
>
> I respectfully disagree with this approach, I think it's heading in the
> wrong direction.
>
> We should be moving towards safe APIs by default, and separating out
> unsafe APIs into separate modules.

I completely agree with separating out unsafe APIs but I don't understand
why modules are the right granularity for this, especially given Haskell's
rather rudimentary module system. As I said, the module-based approach
results in a significant maintainance burden for vector.

> That is what SafeHaskell is about:
> it's not an obscure feature that is only used by things like "Try
> Haskell", the boundary between safety and unsafety is something we
> should all be thinking about.  In that sense, we are all users of
> SafeHaskell.  We should think of it as "good style" and best practice to
> separate safe APIs from unsafe ones.

At the risk of being blunt, I do find SafeHaskell's notion of safety
somewhat obscure. In vector, all unsafe functions have the string "unsafe"
in their name. Here are two examples of functions that don't do bounds
checking:

unsafeIndex :: Vector a -> Int -> a
unsafeRead :: IOVector a -> Int -> IO a

Unless I'm mistaken, SafeHaskell considers the first one unsafe and the
second one safe. Personally, I find vector's current notion of safety much
more useful and wouldn't want to weaken it.

> I would argue against adding any unsafe APIs to the Haskell Platform
> that aren't in a .Unsafe module.  (to what extent that applies to vector
> I don't know, so it may be that I'm causing trouble for the proposal
> here).

To avoid confusion, let's first agree on what an "unsafe API" is. For
vector, "unsafe" basically means no bounds checking and my understanding
is that this is quite different from SafeHaskell's notion of safety. As I
said, such functions have the string "unsafe" in their name. Additionally,
Data.Vector.Storable is entirely unsafe even in the SafeHaskell sense (as
in, it unsafePerformIOs essentially arbitrary code) due to the design of
the Storable class - there are no safe bits there at all. It still uses
"unsafe" to distinguish between functions that do bounds checking and
those that don't. What would be the benefit of moving functions like
unsafeIndex into a separate module (and would it be called
Unsafe.unsafeIndex then? or would it be Unsafe.index?)? Would you advocate
renaming Data.Vector.Storable to Data.Vector.Storable.Unsafe?

Also, you seem to be arguing for both using SafeHaskell and having a
special naming convention for modules with unsafe stuff. Wouldn't one of
those be sufficient?

Roman