Haskell Platform proposal: Add the vector package

[Johan Tibell]

Hi Bas,

On Wed, Jul 11, 2012 at 10:54 AM, Bas van Dijk <v.dijk.bas at gmail.com> 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
> 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.

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

Agree. But see above. SH forces me to use some particular system to
explain my trust to GHC.

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

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
the .Safe module to some other module, breaking clients.

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

The problem is that users of my package want to use SH and thus send
me patches that rewrite my API to support their preference.

Cheers,
Johan