Haskell Platform proposal: Add the vector package

[Bas van Dijk]

On 10 July 2012 22:58, Johan Tibell <johan.tibell at gmail.com> 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 at gmail.com> 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
> ones. This is a traditional type system power vs cost argument in
> other words.
>
> The bad programs rules out by SH are those that have bugs in code
> rejected by SH (e.g. unsafePerformIO, FFI.) I can't even come up with
> an example of such a program. Does anyone have an example of a program
> that's accepted by the current type system but rejected by SH? Another
> way to ask the same question: in adding all those extra Trustworthy,
> Save, and Unsafe language pragmas to e.g. base, were any bugs found?

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.

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

> If you want to write real code and use SH, you need to either avoid
> all these libraries or to trust (as in ghc-pkg trust) all these
> libraries.

Correct

> Despite none of them having had a thorough security review.
> In practice Trustworthy language pragmas on top of modules to make
> code compile. There are 139 modules in base marked as Trustworthy. I
> seriously doubt that they all are.

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.

Personally I don't see the point of the Trustworthy extension. I think
Safe and Unsafe are enough. Importing some module M into a Safe module
is allowed if M is inferred to be Safe or if M's package is trusted. I
think that's the only rule you need.

> Furthermore, you will have to trust
> that the maintainers of those libraries, who often don't care about
> SH, keeps the code in Trusted modules secure or else whatever benefit
> you gained from SH is lost (but you keep the costs.) You will have to
> review the implementation of any new library that you want to unless
> you only use libraries that are completely safe.

I don't see a way around that. The cost of establishing trust in a
package is always on you. You can hire someone to do a safety analysis
but then you still have to trust the result of the analysis. It will
always come back to you.

What would be very useful (but costly) is to have a group of well
known, Haskell hackers (call them the trustees) which perform safety
analysis on packages. The results can than be published on Hackage.

> SH also prevents
> optimizations, like rewriting a particularly hot function in C, as it
> would change its type.

SH does not prevent the optimization. It just doesn't allow it to be
used in a Safe module unless it's trusted.

> SH is much more invasive than your typical language extension. It
> requires maintainers of libraries who don't care about SH to change
> their APIs (!) just to support a yet unproven language extension. The
> reason is that SH is an all or nothing approach. Either all your
> dependencies are SH aware or your code won't compile. This is the
> opposite of how we handle any other language extensions, where people
> can slowly try out new language features in their own code and only
> have people who chose to use that code also have to use that feature
> e.g. if I use type families in a library that depends on containers,
> that doesn't imply that the containers package have to use type
> families. This is however true for SH.

If you don't want to use SH you don't have any restrictions on which
modules you import or export. Just don't mark your module as Safe!

> If we start using TH in our core libraries we risk making those
> libraries more complicated for users to understand and use, without
> much perceivable benefit.

I guess you mean SH instead of TH. Then it's a valid point.

Regards,

Bas