[Haskell-cafe] Idea for hackage feature
pumpkingod at gmail.com
Thu Sep 16 03:00:48 EDT 2010
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
But maybe one day we'll have way more than just "Stability: experimental;
Version: 0.0.1" on hackage, but instead:
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 :)
On Thu, Sep 16, 2010 at 8:21 AM, Ivan Lazar Miljenovic <
ivan.miljenovic at gmail.com> wrote:
> On 16 September 2010 16:04, Mitar <mmitar at gmail.com> 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
> 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 at gmail.com
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe