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 <marlo...@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 _______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
