Haskell Platform proposal: Add the vector package

[Simon Marlow]

On 13/07/2012 05:35, Gregory Collins wrote:
> Hi Simon,
>
> On Thu, Jul 12, 2012 at 10:43 PM, Simon Marlow <marlowsd at gmail.com
> <mailto:marlowsd at gmail.com>> wrote:
>
>     Safe Haskell isn't about catching bugs.  It's about making it
>     possible to program with stronger guarantees than we currently have.
>
>       ...
>
>     Normally when you use an unsafe feature, the purpose is to use it to
>     implement a safe API - if that's the case, all you have to do is add
>     Trustworthy to your language pragma, and the API is available to use
>     from Safe code.
>
>
> The issue I think Johan is complaining about is that this is a very weak
> sauce. If some muppet can upload a package on Hackage that dereferences
> nullPtr and just slap a "{-# LANGUAGE Trustworthy #-}" on the top, then
> we're back exactly where we were before: library users must trust
> library maintainers and/or carefully security audit the code they rely
> on.

We're still better off than before: currently you have to trust *all* 
the code, whereas with Safe Haskell you only have to trust the 
Trustworthy code.

Furthermore, nobody is saying that you as a library maintainer or a user 
have to audit anything.  Only a user that wants to run untrusted code 
has to worry about what they're trusting, and Safe Haskell gives them 
three things they didn't have before: (a) automatic checking for Safe 
code, (b) a way to see which modules have to be trusted, and (c) a 
mechanism for telling the system which packages are trusted.

> If you're asking library authors to do a lot of work to rearchitect
> their module namespaces, and increasing their maintenance overhead for
> the 6-12 months a deprecation cycle would take, I think you have to have
> a compelling story to offer about how life will be better in the end.

Well, first of all I think vector is very much a special case.  It is 
very rare to have a mixed safe/unsafe API.  The majority of libraries 
will need either no changes or a few Trustworthy pragmas.  For evidence 
of this you can see what changes had to be made to the packages that 
come with GHC.

If vector doesn't change to accomodate Safe Haskell, it's not a disaster 
- it just means that clients of vector cannot use Safe.  They can still 
use Trustworthy, so the net result is we'll end up with a few more 
Trustworthy pragmas than before, and users who care about security have 
a bit more trusting to do.

As for whether the story is compelling, apparently I'm not doing a very 
good job of selling it :-)  But I know that at least some people are 
very excited about Safe Haskell already.  One of the anonymous reviewers 
on our paper called it (paraphrased) the most important thing to happen 
in Haskell for a good few years.  Maybe that's overstating it a little, 
but it's clearly important to some users.

> Now, if functions could be cryptographically *signed*, meaning that
> "user X asserts that he's audited this code and it's actually safe",
> then you could start building the web of trust necessary for this
> feature to be useful. (Of course, the code would have to be re-signed
> every time code it depends on changed..... I don't actually think this
> would work!).
>
> As it stands, one miscreant can cause a lot of damage, especially when
> you consider that right now anyone can upload any version of any package
> to Hackage --- Safe Haskell or not.

It makes more sense if you think about it the other way around: there is 
a great deal of Haskell code that we can statically detect does not use 
any unsafe features, and that we can guarantee is type-safe and 
referentially transparent.  The purpose of Safe Haskell is to let GHC do 
that checking for you - so with Safe Haskell you have to trust *less* 
code than before.  The rest of the design falls out from this simple idea.

Cheers,
	Simon