Simon Marlow | 4 Jul 12:59 2012
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)

Simon Marlow | 5 Jul 11:42 2012
Picon

Re: Haskell Platform proposal: Add the vector package

On 04/07/2012 16:33, Roman Leshchinskiy wrote:
> Simon Marlow wrote:
>> 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.

The choice to use the module boundary was made for pragmatic reasons - 
it reduces complexity in the implementation, but also it makes things 
much simpler from the programmer's point of view.  The programmer has a 
clear idea where the boundary lies: in a Safe module, they can only 
import other Safe/Trustworthy modules.  The Safe subset is a collection 
of modules, not some slice of the contents of all modules.  The Haddock 
docs for a module only have to say in one place whether the module is 
considered safe or not.

This is certainly a debatable part of the design, and we went back and 
forth on it once or twice already.  Conceivably it could change in the 
future.  But I don't think this is the right place to discuss the design 
of SafeHaskell, and at least in our experience the current design seems 
to work quite well.

Could you say something more about the maintenance burden?  I imagined 
that you would just separate the unsafe (in the SafeHaskell sense) 
operations into separate modules.

>> That is what SafeHaskell is about:
(Continue reading)

Roman Leshchinskiy | 4 Jul 17:33 2012
Picon
Picon

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)

Roman Leshchinskiy | 5 Jul 15:20 2012
Picon
Picon

Re: Haskell Platform proposal: Add the vector package

Simon Marlow wrote:
> On 04/07/2012 16:33, Roman Leshchinskiy wrote:
>> Simon Marlow wrote:
>>> 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.
>
> The choice to use the module boundary was made for pragmatic reasons -
> it reduces complexity in the implementation, but also it makes things
> much simpler from the programmer's point of view.  The programmer has a
> clear idea where the boundary lies: in a Safe module, they can only
> import other Safe/Trustworthy modules.  The Safe subset is a collection
> of modules, not some slice of the contents of all modules.  The Haddock
> docs for a module only have to say in one place whether the module is
> considered safe or not.
>
> This is certainly a debatable part of the design, and we went back and
> forth on it once or twice already.  Conceivably it could change in the
> future.  But I don't think this is the right place to discuss the design
> of SafeHaskell, and at least in our experience the current design seems
> to work quite well.

I think we're misunderstanding each other slightly here. You seem to be
using "separating out unsafe APIs" and SafeHaskell as synonyms whereas I'm
(Continue reading)

Simon Marlow | 5 Jul 17:21 2012
Picon

Re: Haskell Platform proposal: Add the vector package

On 05/07/2012 14:20, Roman Leshchinskiy wrote:

>  From the maintainance point of view, this would become easier if I had
> *.Unsafe modules rather than the *.Safe ones. But this is a signficant
> restructuring and the only reason to do it would be to support
> SafeHaskell. Moreover, I believe (though I haven't checked) that there are
> calls from safe to unsafe functions and vice versa. So now I would have to
> have a common base module with both safe and unsafe functions and reexport
> those from the right top-level module. No, this just isn't feasible.

It looks pretty straightforward to me.  For each M:

  - rename M to M.Internal (or suitable alternative)
  - rename M.Safe to M
  - add a (small) M.Unsafe where necessary

Of course, I can't force you to make this change, I can only say that I 
think it would be worthwhile, and now is a good time to make the change 
- it will be more difficult to do it later when the package is already 
in the platform.  I understand your objections, but I don't think any of 
them is a showstopper.

Standing back for a minute, one argument against doing this was that 
"SafeHaskell isn't widely used".  In order for Safe Haskell to be widely 
used, we have to make safe APIs available - if we don't, then clients of 
the library cannot use {-# LANGUAGE Safe #-}, and the chain is broken. 
Arguably we should be moving towards Safe being something that we 
routinely put at the top of our modules, and my motivation is just to 
nudge us in that direction.

(Continue reading)

Johan Tibell | 10 Jul 22:58 2012
Picon

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)

Bas van Dijk | 11 Jul 19:54 2012
Picon

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)

Johan Tibell | 11 Jul 20:30 2012
Picon

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)

Henning Thielemann | 11 Jul 20:49 2012
Picon

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


On Wed, 11 Jul 2012, Johan Tibell wrote:

>> Trustworthy obviously doesn't mean no-bugs. It just means that the
>> module author claims that the API of the module can't be used to
>> violate certain guarantees. Whether you trust his claim and how to
>> establish this trust is up to you. For some applications it will be
>> enough to know that the author is a Haskell hacker with a good
>> track-record, for other applications a complete formal-proof of the
>> module is required.
>
> I claim this is completely orthogonal to SH. I already today have to
> trust that e.g. Bryan didn't make unsafe use of unsafePerformIO in
> text such that my application is susceptible to e.g. buffer overflows.

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 guess I wasn't explicit enough here. I believe Simon's argument is
> that we should have .Safe modules so people don't have to trust code.
> However, rewriting a function in C would require it to be moved from
(Continue reading)

Bas van Dijk | 11 Jul 23:11 2012
Picon

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

Gmane