On 13/07/2012 05:35, Gregory Collins wrote:
Hi Simon,
On Thu, Jul 12, 2012 at 10:43 PM, Simon Marlow <marlo...@gmail.com
<mailto:marlo...@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
_______________________________________________
Haskell-platform mailing list
Haskell-platform@projects.haskell.org
http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
