[Haskell-cafe] Idea for hackage feature

Ivan Lazar Miljenovic ivan.miljenovic at gmail.com
Thu Sep 16 05:47:46 EDT 2010

On 16 September 2010 17:00, Daniel Peebles <pumpkingod at gmail.com> wrote:
> 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 :)

Problem is: whilst we might be able to derive the impurity stuff, and
the usage is done by examing reverse dependencies, I'm not sure how
you would categorise the stability and quality.  Furthermore, the test
coverage bit presumably requires developers enable hpc when building
tests, and if those tests are optional then wouldn't HPC's figures be
slightly off since the test suite is now included in the amount of
source you have compared to what most people see?

> Dan
> 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
>> "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 at gmail.com
>> IvanMiljenovic.wordpress.com
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe

Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com

More information about the Haskell-Cafe mailing list