qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method)

Wed Feb 26 15:00:40 UTC 2014

Can we all zoom out for a moment?

Can we turn this into a technology problem we can solve, rather than an
anthropological issue?

what about adding some sort of model of "module type signature" tooling to
cabal/cabal-install experimentally (and perhaps eventually GHC?).

A lot of our package version problems stem from ...... our *untyped* module
system.  We currently don't have any static ways of reasoning / checking if
two packages of modules are actually intercompatible without actually
compiling them! But the information is there! Yes we need to figure out how
such a design would support type classes gracefully (in a way we can all be
happy with), but thats just a bullet point, not a barrier.

Theres some smart folks who've started exploring the design space in their
research (its a huge design space), but perhaps we as a community should
actually commit to a "k year plan, for some finite k <= 5" to actually work
out typeful tooling for this recurrent library tooling pain, which requires
that WE EXPERIMENT :)

seriously, lets stop focusing on the symptom, and do we what we do best,
collaborate to build tools that systematically improve all of our
respective approaches ('cause lets be honest, i don't think the camps here
are going to change, and tribalism never helps anyone).

basically everyone's correct and wrong because its such a darn high
dimensional problem that none of us have the time to correctly communicate
the full nuances of the respective stances.

As always, sending an email to the libraries list when theres been this
many people on the thread is a dangerous thing, but sometimes danger is my
middle name.

i imagine several of you are writing up haskell module type systems papers
for ICFP when not opining on this thread (not really, but I wish!)

let me start this (hopefully useful aside) with some thoughts

1) pinning package deps to a fixed version is a social construct for
encoding "i want this exact set of operations with this semantics"

2) saying i want dependency P to  satisfy version range ">= A  && < B" is a
way of saying "assuming my understanding of the range of code semantics and
module types exposed over this version range is true / consistent, my code
can correctly work over this range"

3) even if we had decent module types and ways of say "code works over this
set of interfaces over this version range", versions and things like PVP
still have value in communicating when a package is likely to be the same
or different

4) cabal does need a proper SMT solver tool for handling version
constraints as is, which is a totally unrelated problem, but another fun
one thats actually resolvable by way of using technology

seriously, lets all zoom out of ask "how can we come up with a roadmap for
evolving haskell tooling that solves the underlying need that this whole
thread is indirectly about".  And no it needs to be tool that doesn't pin
everything to a single version, thats for APPs not LIBRARIES :)

-Carter

On Wed, Feb 26, 2014 at 7:05 AM, Michael Snoyman <michael at snoyman.com>wrote:

>
>
>
> On Wed, Feb 26, 2014 at 1:47 PM, Alain O'Dea <alain.odea at gmail.com> wrote:
>
>> On Feb 26, 2014, at 7:11, Michael Snoyman <michael at snoyman.com> wrote:
>>
>>
>>
>> I disagree with that assertion. I get plenty of complaints from users
>> about trying to install packages and getting "confusing error messages"
>> about cabal plan mismatches. I don't disagree that the PVP does make the
>> user experience better in some cases. What I disagree with is the
>> implication that it makes the user experience better in *all* cases. This
>> is simply not a black-and-white issue.
>>
>> Michael
>>
>>
>> This is not a new problem.
>>
>> Java users faced it with Maven and it was solved by curation of Maven
>> Central and the ability to add outside repositories as needed.
>>
>> Node.js users faced it with NPM and solved it with dependency freezing.
>>
>> Ruby users faced it with Gem and solved it with dependency freezing.
>>
>>
> You've presented three examples of other languages solving the problems
> using the two techniques I've been advocating through this thread: curation
> and dependency freezing. Is there an example of a language that took an
> approach like the PVP and succeeded in solving it?
>
>
>> I imagine there are a world of different solutions to this problem.  The
>> PVP isn't a complete solution, but I consider it to be a sensible baseline
>> (like code style conventions and warning free builds) and it appears to me
>> to be in line with best practices from packaging systems of many other
>> languages.
>>
>> What follows is my opinion, and it comes from a position of relative
>> inexperience with Haskell and considerable experience operating on other
>> language communities.
>>
>> I feel that the PVP should be encouraged and violations should be
>> considered bugs. Users and concerned community members should report them
>> to maintainers.
>>
>
> Please, please, please don't actually encourage this. There are many
> things which I consider bad practice in Haskell code. I don't open up bug
> reports against each package that disagrees with me. If a package on
> Hackage in fact does *not* build with some dependency it claims to build
> against, that's a perfectly reasonable thing to report (and I do so on a
> regular basis via Stackage). But insisting that people add upper bounds
> when they've clearly stated they do not want to is crossing the line.
>
> Michael
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140226/f038264b/attachment.html>