Re: [Haskell-cafe] Idea for hackage feature

As we were discussing in #haskell, it would have to be more involved than just a taint bit. A listing showing the "taint sources" of a given package would give you confidence in its good behavior. For example, if my nice, pure package's taint list showed that my only taint sources were through my dependencies on base and bytestring, people could trust my program not to launch missiles behind their backs. This would essentially involve traversing transitive dependencies and looking for any module that imports one of the unsafe modules and uses any function from them (including GHC.Prim). This seems like it could be done fairly efficiently, if you just try to do it on the module or package level. At the function level, it would be a lot more computationally intensive, but would be more or less the same idea. I like the idea, but I don't think any formal proof of unsafeness is feasible. We already can't prove arbitrary properties about even our pure code, and proving stuff about impure code would require modeling the outside world and proving your code safe under that model. Anyone reading the proof would have to accept your model of the outside world as well as verifying your proof. But maybe one day we'll have way more than just "Stability: experimental; Version: 0.0.1" on hackage, but instead: Stability: experimental Version: 0.0.1 Test coverage: 98% User stability rating: 86% User API quality rating: 56% Local sources of impurity: none Transitive sources of impurity: bytestring, base Used by: 37 packages [click to see them] But that's just a dream, and the impurity measures seem like a decent goal in the mean time :) Dan On Thu, Sep 16, 2010 at 8:21 AM, Ivan Lazar Miljenovic < ivan.miljenovic@gmail.com> wrote:

On 16 September 2010 16:04, Mitar wrote:

...

Hi!

I just got an idea for hackage feature. All functions/modules listed there could have some mark if they or any function/module they use uses an unsafe* function. Of course this will make probably almost everything marked as unsafe, but this is the idea - to raise awareness about that so that you can prefer some function/implementation over another.

Of course marking/tagging everything as unsafe is not really useful. Because of this I propose that then community votes/vouches on correctness/stability of implementations and this would then influence the how unsafe given function really is (or is according to community, if we are more precise). Of course it would be even better that every function using unsafe would have also a formal proof but as we cannot believe that we will prove everything in a feasible feature we could maybe opt for such "crowd intelligence" approach. We cannot have a Turing machine, but maybe we can have crowd. ;-)

(Of course low number of found bugs and good unit test code coverage can then positively influence crowd, so authors would be motivated to assure that.)

Comments? Opinions?

Because I really hate that I try to keep my code pure and separate IO from everything else and then somewhere deep in there some unsafe* lurks. (Ah, yes, a side effect of this tagging/marks would be also that you would be able to see where all those unsafe* calls are for a given function, so you would be able to fast jump (with link) to a given line in code and evaluate circumstances in which that unsafe* call is made. And then vote/vouch once you discover that it is probably pretty safe.)

The problem with this is: unsafe* functions would be better called

"yesIGuaranteeThatUsingThisFunctionDoesResultInAReferentiallyTransparentEntityAndItsOKForMeToUseIt*". They are "unsafe" in that you shouldn't use them blindly.

Seeing as how lazy IO relies on various unsafe* functions, as do bytestrings, this means that any program that uses them is subsequently "tainted".

A much better idea would be to have some kind of compilation warning unless you can prove that you're using the unsafe* function in a safe fashion, but such a proof is unlikely to be easily proven in a rigorous fashion nor mechanically checkable (and would delay compilation times).

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe