[Haskell-cafe] Idea for hackage feature

[Daniel Peebles]

Yeah, those other things were part of the "bigger picture" that I hope
hackage will get some day: two axes of user rating, plus optional support
for visualizing things like test coverage and regression tests that you
include in your cabal file (cabal test was being worked on during one of
this year's GSOC for example). I was just trying to show what this would get
us one step closer to :P

On Thu, Sep 16, 2010 at 11:47 AM, Ivan Lazar Miljenovic <
ivan.miljenovic at gmail.com> wrote:

> 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
> IvanMiljenovic.wordpress.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100916/323fdc0a/attachment.html