Haskell Platform proposal: Add the vector package

[Johan Tibell]

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?

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.

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. 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. 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. SH also prevents
optimizations, like rewriting a particularly hot function in C, as it
would change its type.

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

Cheers,
Johan