headers
Simon Marlow | 4 Jul 2012 12:59
Picon

Re: Haskell Platform proposal: Add the vector package

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@...> 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.  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.

I would argue against adding any unsafe APIs to the Haskell Platform
(Continue reading)

Permalink | Reply | 72 comments |
headers
Roman Leshchinskiy | 4 Jul 2012 17:33
Picon
Picon
Favicon

Re: Haskell Platform proposal: Add the vector package

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@...>
>>> 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.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Johan Tibell | 10 Jul 2012 22:58
Picon
Gravatar

Re: Haskell Platform proposal: Add the vector package

Hi Simon,

Sorry for the late reply, I was on vacation.

Let me preface my response below by saying that I think SafeHaskell
(SH) is an interesting and worthwhile research project and this isn't
meant as a diss of SH as whole. Also, my arguments below looks at SH
from the perspective of the average Haskell user i.e. someone who's
not trying to run untrusted code ala "Try Haskell" or Google
AppEngine.

On Wed, Jul 4, 2012 at 3:59 AM, Simon Marlow <marlowsd@...> wrote:
> 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.  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.
>
> 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).

It's hard to argue against "moving towards safe APIs by default." What
I'm going to argue is that SH's extension to the type system (i.e. its
definition of safe and unsafe) doesn't exclude many bad programs that
aren't already excluded by the type system and excludes many good
(Continue reading)

Permalink | Reply | 67 comments |
headers
Bas van Dijk | 11 Jul 2012 19:54
Picon
Gravatar

Re: Haskell Platform proposal: Add the vector package

On 10 July 2012 22:58, Johan Tibell <johan.tibell@...> wrote:
> Hi Simon,
>
> Sorry for the late reply, I was on vacation.
>
> Let me preface my response below by saying that I think SafeHaskell
> (SH) is an interesting and worthwhile research project and this isn't
> meant as a diss of SH as whole. Also, my arguments below looks at SH
> from the perspective of the average Haskell user i.e. someone who's
> not trying to run untrusted code ala "Try Haskell" or Google
> AppEngine.
>
> On Wed, Jul 4, 2012 at 3:59 AM, Simon Marlow <marlowsd@...> wrote:
>> 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.  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.
>>
>> 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).
>
> It's hard to argue against "moving towards safe APIs by default." What
> I'm going to argue is that SH's extension to the type system (i.e. its
> definition of safe and unsafe) doesn't exclude many bad programs that
(Continue reading)

Permalink | Reply | 38 comments |
headers
Johan Tibell | 11 Jul 2012 20:30
Picon
Gravatar

Re: Haskell Platform proposal: Add the vector package

Hi Bas,

On Wed, Jul 11, 2012 at 10:54 AM, Bas van Dijk <v.dijk.bas@...> wrote:
> I don't think the goal of using SH in base was to catch bugs in base.
> I think the goal was to mark which parts of base are safe and, most
> importantly, which parts are unsafe.

But what is the goal then? Simon suggested that SH is useful for
people who don't work with potentially malicious code (but perhaps you
don't agree.)

> > The good programs that are rules out by SH is any program that uses a
> > binding to a C library (all FFI imports are unsafe), any program that
> > uses unsafePerformIO or other unsafe functions in its implementation.
> > The latter group includes most of our widely used libraries, including
> > bytestring, vector, network (almost all functions are bindings to C),
> > binary, base, etc. For example, text can't be used as it's UTF-8
> > decoder is written in C for speed. We'd have to maintain a separate
> > implementation of the UTF-8 decoder for use by SH users.
>
> No we don't. SH users can just import text's decoder in a Safe module
> if they mark the text package as trusted.

I should have been more explicit here. Simon's suggestion seems to be
that we should reorganize all of our core libraries so that users
don't have to trust (very many) libraries. More to the point, we don't
need all these .Safe modules if users are fine just trusting the whole
vector package.

> Trustworthy obviously doesn't mean no-bugs. It just means that the
(Continue reading)

Permalink | Reply | 37 comments |
headers
Bas van Dijk | 11 Jul 2012 23:11
Picon
Gravatar

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

On 11 July 2012 20:49, Henning Thielemann
<lemming@...> wrote:
> I think the idea was to have Unsafe modules and move the unsafe functions
> there. :-)

Indeed. I don't see the point about having .Safe modules. Modules
should be safe by default as you mentioned before. I guess the reason
we have .Safe modules in base and vector is for backwards
compatibility.

The ideal, but currently, impossible way of dealing with this is to
mark the _export_ of unsafe functions in a module as DEPRECATED and in
a later version remove the unsafe functions and mark the module as
Trustworthy. However this requires support for deprecating exports:

http://hackage.haskell.org/trac/ghc/ticket/4879

Bas
Permalink | Reply | 27 comments |
headers
Johan Tibell | 11 Jul 2012 23:43
Picon
Gravatar

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

On Wed, Jul 11, 2012 at 11:49 AM, Henning Thielemann
<lemming@...> wrote:
> I think the difference is that currently we have to know the set of unsafe
> functions like unsafePerformIO and search for them in an imported package.
> This work is now done by the compiler which tells me if there is something
> suspicious in the package. If a package does not call any unsafe function
> the compiler can tell me. By searching for unsafePerformIO and friends I
> could miss something.
>
> I think that the SafeHaskell extension is also worth because some
> programmers do not seem to care about the use of unsafePerformIO. I hope
> that compiler checks about the use unsafe functions will more discourage the
> use of unsafePerformIO.

I don't find trusting the authors of the packages I use to be a
burden. I already have to trust them with writing correct code and fix
bugs when they fail to do so. If they use unsafe functions I trust
they do so for good reasons. What would I do with the information that
text uses unsafePerformIO somewhere? Most likely nothing.

> I think the idea was to have Unsafe modules and move the unsafe functions
> there. :-)

This would break everything. Every single user of the vector library
would break. Same goes for many other libraries. I cannot stress how
dangerous an idea is from a software engineering and Haskell adoption
perspective. You don't break widely used APIs. Look at Python 3. They
broken a few things (not all libraries!) and several years down the
road most people still don't use Python 3 because of it.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Johan Tibell | 11 Jul 2012 23:45
Picon
Gravatar

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

On Wed, Jul 11, 2012 at 2:11 PM, Bas van Dijk <v.dijk.bas@...> wrote:
> On 11 July 2012 20:49, Henning Thielemann
<lemming@...> wrote:
>> I think the idea was to have Unsafe modules and move the unsafe functions
>> there. :-)
>
> Indeed. I don't see the point about having .Safe modules. Modules
> should be safe by default as you mentioned before. I guess the reason
> we have .Safe modules in base and vector is for backwards
> compatibility.
>
> The ideal, but currently, impossible way of dealing with this is to
> mark the _export_ of unsafe functions in a module as DEPRECATED and in
> a later version remove the unsafe functions and mark the module as
> Trustworthy. However this requires support for deprecating exports:
>
> http://hackage.haskell.org/trac/ghc/ticket/4879

But why? The number of people who will benefit from this mass
deprecation/mass migration is tiny.

-- Johan
Permalink | Reply | 22 comments |
headers
Henning Thielemann | 11 Jul 2012 23:46
Picon

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


On Wed, 11 Jul 2012, Bas van Dijk wrote:

> The ideal, but currently, impossible way of dealing with this is to
> mark the _export_ of unsafe functions in a module as DEPRECATED and in
> a later version remove the unsafe functions and mark the module as
> Trustworthy. However this requires support for deprecating exports:

We can easily re-define functions, like

module Old where

import MyMod.Unsafe as Unsafe

{-# DEPRECATED "unsafeDoSomething" #-}
unsafeDoSomething :: a -> b
unsafeDoSomething = Unsafe.unsafeDoSomething

Do we really need deprecating exports?
Permalink | Reply | 3 comments |
headers
Bas van Dijk | 12 Jul 2012 00:08
Picon
Gravatar

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

On 11 July 2012 23:45, Johan Tibell <johan.tibell@...> wrote:
> On Wed, Jul 11, 2012 at 2:11 PM, Bas van Dijk <v.dijk.bas@...> wrote:
>> On 11 July 2012 20:49, Henning Thielemann
<lemming@...> wrote:
>>> I think the idea was to have Unsafe modules and move the unsafe functions
>>> there. :-)
>>
>> Indeed. I don't see the point about having .Safe modules. Modules
>> should be safe by default as you mentioned before. I guess the reason
>> we have .Safe modules in base and vector is for backwards
>> compatibility.
>>
>> The ideal, but currently, impossible way of dealing with this is to
>> mark the _export_ of unsafe functions in a module as DEPRECATED and in
>> a later version remove the unsafe functions and mark the module as
>> Trustworthy. However this requires support for deprecating exports:
>>
>> http://hackage.haskell.org/trac/ghc/ticket/4879
>
> But why? The number of people who will benefit from this mass
> deprecation/mass migration is tiny.

While I agree that the number of people who will benefit is tiny I
don't think it's a "mass" deprecation. In base there are only 7
functions that need to be deprecated:

* Control.Monad.ST.Lazy.unsafeInterleaveST
* Control.Monad.ST.Lazy.unsafeIOToST

* Control.Monad.ST.unsafeInterleaveST
(Continue reading)

Permalink | Reply | 21 comments |

Gmane