Simon, I'm still trying to figure out if there is a sane way to support Safe Haskell's module structure in vector. I'll post my thoughts later. Here are a couple of quick questions and observations, though.
Simon Marlow wrote: > Myth #1 seems to be that Safe Haskell excludes large amounts of Haskell > code that people want to write. Not at all! 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. 99% of Hackage > should be either Safe or Trustworthy. We know that 27% is already > inferred Safe (see the paper), and a lot of the rest is just waiting for > other libraries to add Trustworthy where necessary. Is "inferred Safe" the same as being marked "Safe-Infered" on Hackage? It does say that for Data.Vector.Unboxed, for instance, but that module certainly contains unsafe functions. >> 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. > > Whether you believe those claims or not is entirely up to you. Someone > who is relying on Haskell for security has to trust a lot of things - > GHC itself, the RTS, not to mention the hardware. Safe Haskell just > makes it a bit clearer what you have to trust, and allows GHC to > automate some of the checking. FWIW, I went looking through the libraries and GHC does indeed come with a Trustworthy unsafePerformIO out of the box (it's in Data.Binary.Builder.Internal). Now, I'm not trying to knock the binary package. I think it just shows that unsafe functions *will* slip through the net, even in code written by absolute experts, so Johan's concerns are quite warranted. >> 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 (!) > > It will be very rare for this to happen. The vast majority of packages > do not expose unsafe APIs, so at most all that will be needed is some > Trustworthy pragmas, and in many cases no changes at all are needed. In > the very few cases where there is a mixed safe/unsafe API, and we really > care about Safe access to the safe parts, then the unsafe parts should > be moved into a .Unsafe module. It seems that anything array-related would have to be split up in this way, just like it was in base. FWIW, I think Debug.Trace should be split up, too, since traceIO and especially traceEventIO are perfectly safe and useful. What about floating point arithmetic? Is it safe if I turn on FP exceptions? > I don't think adding a few Trustworthy pragmas is very onerous, and > arguably it's good documentation anyway. One problem I noticed here is Haskell's treatment of instances. It just isn't always obvious what exactly your module exports. It's easy to say that a particular function is safe. It is much harder to say the same for a whole module because you might be importing and hence exporting unsafe instances without realising. I think more language support would be needed here. > Of course it's your prerogative as a library maintainer to decide > whether to use Trustworthy or not. For the platform I think the bar is > a little higher, and cleanly separating safe from unsafe APIs is > warranted. Independent of vector, I'm against making Safe Haskell compliance a prerequisite for anything at this point. If it proves itself and if enough people start using it and relying on it - sure. But right now, it an experimental language extension with a very small user base. Roman _______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
