Proposal: Explicitly require "Data.Bits.bit (-1) == 0" property

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
149 messages Options
12345 ... 8
Reply | Threaded
Open this post in threaded view
|

Re: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method

Henning Thielemann-4
Am 24.02.2014 18:34, schrieb Twan van Laarhoven:
> I agree with Edward that it would be better to reserve 'zero' for
> something like an additive identity.

Why would you want to reserve Bits.zero for an additive zero? This makes
no sense.

> I'll withdraw my +1 for the name `zero`, in favor of +1 for `zeroBits`.

What is bad about Bits.zero?

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method

Brandon Allbery
On Mon, Feb 24, 2014 at 12:41 PM, Henning Thielemann <[hidden email]> wrote:
Am <a href="tel:24.02.2014%2018" value="+12402201418" target="_blank">24.02.2014 18:34, schrieb Twan van Laarhoven:

I agree with Edward that it would be better to reserve 'zero' for
something like an additive identity.

Why would you want to reserve Bits.zero for an additive zero? This makes no sense.

There is something vaguely smelly about specifically omitting the context

it is an annoyingly common name to take for
> such an often unqualified import.

in the original message. Yes, we're quite aware you do not consider it legitimate. Distorting someone else's meaning to press your point is also not legitimate.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method

Henning Thielemann-4
In reply to this post by Herbert Valerio Riedel
Am 22.02.2014 11:03, schrieb Herbert Valerio Riedel:

>      So far there doesn't seem to be a very clear preference for
>      'zeroBits' over 'zero'. It might help, if those how expressed some
>      kind of support for both variants could clarify if their preference
>      has any bias towards 'zeroBits' or 'zero'.


It turns out to be another round of the discussion qualified imports vs.
unqualified imports. Many Haskell programmers seem to avoid qualified
imports at all costs. I can't explain that, maybe the proponents of
qualified imports can do it.

But I suspect that what we really discuss is something more critical:
It's about conformance to PVP vs. non-conformance to PVP and thus
letting Hackage users fix packages of lazy programmers. I guess, what
the proponents of "zeroBit" really want, is to import unqualified,
implicitly and without version bounds when importing 'base'. If you want
to conform to the PVP and thus give the user a good experience, then you
have to give up one of these three conveniences. Strict version bounds
on "base" requires to update Cabal descriptions frequently. I guess you
don't want that. Explicit imports mean that you have to maintain import
lists. I guess you don't want that as well. The only convenient option
is to import qualified. But then Bits.zero is much better than
Bits.zeroBits.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method

Henning Thielemann-4
In reply to this post by Brandon Allbery
Am 24.02.2014 18:57, schrieb Brandon Allbery:

> On Mon, Feb 24, 2014 at 12:41 PM, Henning Thielemann
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Am 24.02.2014 18 <tel:24.02.2014%2018>:34, schrieb Twan van Laarhoven:
>
>         I agree with Edward that it would be better to reserve 'zero' for
>         something like an additive identity.
>
>
>     Why would you want to reserve Bits.zero for an additive zero? This
>     makes no sense.
>
>
> There is something vaguely smelly about specifically omitting the context
>
>  > it is an annoyingly common name to take for
>> such an often unqualified import.
>
> in the original message. Yes, we're quite aware you do not consider it
> legitimate. Distorting someone else's meaning to press your point is
> also not legitimate.

The phrase "reserve 'zero'" suggests that once we choose Bits.zero, the
identifier 'zero' is reserved once and for all and cannot be used for
something different anymore. That is, this phrasing removes the option
of qualified imports from the scope and thus generates the wrong context.

Can someone please, please tell me why we must avoid qualified imports
at all costs? Why is this option repeatedly ignored when just saying
zeroBits (+1) or zero (-1)?

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method

Edward Kmett-2
Henning,

As far as I know the only serious proponent of using qualified imports for all imports all the time is you.

Name conflicts don't affect you. We get that. We got that loud and clear virtually every time the naming of pretty much anything has arisen on this mailing list for the last few years.

That doesn't change the fact that your practice and common practice diverge.

I'm hard pressed to like an option that causes pain for the sloppy majority.

-Edward


On Mon, Feb 24, 2014 at 1:09 PM, Henning Thielemann <[hidden email]> wrote:
Am <a href="tel:24.02.2014%2018" value="+12402201418" target="_blank">24.02.2014 18:57, schrieb Brandon Allbery:
On Mon, Feb 24, 2014 at 12:41 PM, Henning Thielemann
<[hidden email]
<mailto:[hidden email]>> wrote:

    Am <a href="tel:24.02.2014%2018" value="+12402201418" target="_blank">24.02.2014 18 <tel:24.02.2014%2018>:34, schrieb Twan van Laarhoven:


        I agree with Edward that it would be better to reserve 'zero' for
        something like an additive identity.


    Why would you want to reserve Bits.zero for an additive zero? This
    makes no sense.


There is something vaguely smelly about specifically omitting the context

 > it is an annoyingly common name to take for
such an often unqualified import.

in the original message. Yes, we're quite aware you do not consider it
legitimate. Distorting someone else's meaning to press your point is
also not legitimate.

The phrase "reserve 'zero'" suggests that once we choose Bits.zero, the identifier 'zero' is reserved once and for all and cannot be used for something different anymore. That is, this phrasing removes the option of qualified imports from the scope and thus generates the wrong context.

Can someone please, please tell me why we must avoid qualified imports at all costs? Why is this option repeatedly ignored when just saying zeroBits (+1) or zero (-1)?


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method

Casey McCann-2
In reply to this post by Henning Thielemann-4
On Mon, Feb 24, 2014 at 1:09 PM, Henning Thielemann
<[hidden email]> wrote:

> Am 24.02.2014 18:57, schrieb Brandon Allbery:
>>
>> There is something vaguely smelly about specifically omitting the context
>>
>>  > it is an annoyingly common name to take for
>>>
>>> such an often unqualified import.
>>
>>
>> in the original message. Yes, we're quite aware you do not consider it
>> legitimate. Distorting someone else's meaning to press your point is
>> also not legitimate.
>
>
> The phrase "reserve 'zero'" suggests that once we choose Bits.zero, the
> identifier 'zero' is reserved once and for all and cannot be used for
> something different anymore. That is, this phrasing removes the option of
> qualified imports from the scope and thus generates the wrong context.
>
> Can someone please, please tell me why we must avoid qualified imports at
> all costs? Why is this option repeatedly ignored when just saying zeroBits
> (+1) or zero (-1)?

Because it is a thoroughly irrelevant option, empirically speaking, on
account of approximately nobody actually using Data.Bits that way.

Based on a quick Google search of hackage, here are the use cases
wherein Data.Bits is imported qualified:

- Intentionally defining functions with clashing names which are then
exported with the intent of being imported unqualified elsewhere
- Machine-generated code too lazy to worry about namespace issues
- Commented-out import lines

Your own code, by the way, falling into the third category.

If your primary contention here is that core library APIs should be
re-designed based not on how they are actually used in practice, but
rather on pie-in-the-sky notions regarding how they ought to be used
in some uniquely ideal world, perhaps you should raise that point in
its own thread rather than endlessly hijacking discussions about
modules you may or may not even use. A debate over painting new doors
for a bikeshed is not the time or place to propose tearing down the
entire shed and building a gazebo in its place.


As for the real question, I'd prefer something along the lines of
"clearedBits". Only the haddock comments on the shift functions use
1/0 to talk about individual bits, the function names and the other
haddocks consistently use set/clear. It's not a big deal though.

I'm also wondering if anyone has examples of the name "zero" in code
that's actually used and doesn't expect to stomp all over the
namespace anyway by redefining arithmetic. "zero" sounds suspiciously
like one of those names that's so common nobody actually uses it
because they don't want to clash with all the other places it's being
conspicuously not used. (see: mzero, zeroArrow...)

I'm not at all sure Data.Bits is the flag we'd want to plant in it
regardless, but it would be nice to know if "zero" is actually in
common use.

- C.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method

Dan Doel
On Mon, Feb 24, 2014 at 2:56 PM, Casey McCann <[hidden email]> wrote:
Because it is a thoroughly irrelevant option, empirically speaking, on
account of approximately nobody actually using Data.Bits that way.

There's some reason for that, too. Bits has operators, which are especially ugly when qualified, and I suspect most people are even more annoyed by using two import statements to manage this than they are about using qualified imports in the first place.

In fact, most of the library has unique enough names that it needn't be imported qualified, and qualifying would make code read worse (to me, and I'm sure others; x `Bits.shiftR` n). So in this case, we'd be adding one function that encourages qualification to a module that otherwise doesn't.

-- Dan

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method

Evan Laforge
In reply to this post by Edward Kmett-2
On Mon, Feb 24, 2014 at 11:56 AM, Edward Kmett <[hidden email]> wrote:
> Henning,
>
> As far as I know the only serious proponent of using qualified imports for
> all imports all the time is you.

Well, so am I, but I'm not the crusading sort.  Unqualified import as
default is definitely the dominant style, to the point where language
extensions tend to assume it, e.g. record puns, or even the whole
shared record names debate.

Interestingly, python and java seem to lean the other way.  Not sure
about ocaml, but I remember qualified names from back in the day.  A
culture thing, I guess.  Infix operators and backticks are uniquely
haskelly things that probably contribute a little.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Henning Thielemann-4
In reply to this post by Edward Kmett-2
Am 24.02.2014 20:56, schrieb Edward Kmett:

> As far as I know the only serious proponent of using qualified imports
> for all imports /all/ the time is you.

First, there are some important packages like containers and bytestring
that clearly are intended for qualified imports, and I really like that
insertFM was replaced by Map.insert in the past. Second, your argument
addresses a person not the issue.

> Name conflicts don't affect you. We get that. We got that loud and clear
> virtually every time the naming of pretty much anything has arisen on
> this mailing list for the last few years.

Sure, because there is no general discussion about the pros and cons of
various naming styles. That's why it is discussed for every single
identifier. How should a general discussion look like? What could be its
outcome? That I am no longer allowed to propose the qualified import style?

> That doesn't change the fact that your practice and common practice diverge.

And I challenge the common practice, because it prefers convenience for
few package authors over convenience for many package user (that may not
even be a Haskell programmer).

For an example let me look at your lens package. You use unqualified and
implicit imports. That is according to the PVP you would need to use
tight version bounds like "containers >=0.4.0 && <0.5.0.1", but you
don't. That is, your package does not conform to the PVP. It implies
that users may have to fix your package when one of the imported
packages starts to export identifiers that clash with those from "lens".
Of course, there is no need to conform to the PVP. But it works best if
many people adhere to it.

I have not written the PVP, that is, there must be at least one other
person who cares. I understand the need for it and try to comply to it.
Maybe I am in a minority. Looking at Hackage it seems I am in a
minority. But I believe I am in the minority who cares whether packages
work together. Shall I capitulate to the majority which does not seem to
care about package interoperability?

I am also ok if sloppy common practice happens in many Hackage packages.
I do not need to use them. But I need to use 'base'.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method

Henning Thielemann-4
In reply to this post by Dan Doel
Am 24.02.2014 21:24, schrieb Dan Doel:

> On Mon, Feb 24, 2014 at 2:56 PM, Casey McCann <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Because it is a thoroughly irrelevant option, empirically speaking, on
>     account of approximately nobody actually using Data.Bits that way.
>
>
> There's some reason for that, too. Bits has operators, which are
> especially ugly when qualified, and I suspect most people are even more
> annoyed by using two import statements to manage this than they are
> about using qualified imports in the first place.

For Data.Map we are used to write two import statements. It's not that
uncommon.

But I agree that qualification and infix operators don't work well
together. That said, I am also not happy with 'rotate' and 'shift' being
designed for infix use, since this way I cannot use (.) and ($) for
composition of bit manipulations.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method

Henning Thielemann-4
In reply to this post by Casey McCann-2
Am 24.02.2014 20:56, schrieb Casey McCann:

> As for the real question, I'd prefer something along the lines of
> "clearedBits".

Great, lets call it Bits.cleared, this would make sense with
qualification and would not risk name clashes for unqualified use. This
would serve both camps.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method

Ian Lynagh
In reply to this post by Anthony Cowley
On Sat, Feb 22, 2014 at 02:51:24PM -0500, Anthony Cowley wrote:
> I am -1 on the name zero. I don't think importing Data.Bits unqualified is uncommon at all, and zero is prime naming real estate. I am +0.5 on the addition overall, as most uses of Bits are with types that also have Num instances.

For those that don't have a Num instance, "zero" may not make as much
sense.

Perhaps something like noBits would be better. And FiniteBits may also
want an allBits?


Thanks
Ian

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Henning Thielemann-4
In reply to this post by Henning Thielemann-4
Am 24.02.2014 21:30, schrieb Henning Thielemann:

> For an example let me look at your lens package. You use unqualified and
> implicit imports. That is according to the PVP you would need to use
> tight version bounds like "containers >=0.4.0 && <0.5.0.1", but you
> don't.

Sorry, it must be "containers >=0.4.0 && <0.5.1", but it is "containers
 >=0.4.0 && <0.6".

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Edward Kmett-2
...and I have had a half dozen problems caused by this policy in 5 years precisely because people are careful with their names in the packages I do depend upon.

What I maintain now is approximately a full time job. Depending on minor versions and multiplying my workload by a nontrivial factor to eliminate a non-problem isn't going to happen.

-Edward

> On Feb 24, 2014, at 4:43 PM, Henning Thielemann <[hidden email]> wrote:
>
> Am 24.02.2014 21:30, schrieb Henning Thielemann:
>
>> For an example let me look at your lens package. You use unqualified and
>> implicit imports. That is according to the PVP you would need to use
>> tight version bounds like "containers >=0.4.0 && <0.5.0.1", but you
>> don't.
>
> Sorry, it must be "containers >=0.4.0 && <0.5.1", but it is "containers >=0.4.0 && <0.6".
>
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

qualification of Data.Map (Was: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method)

Henning Thielemann-4
In reply to this post by Henning Thielemann-4
Am 24.02.2014 22:37, schrieb Casey McCann:

> The need for qualification with Data.Map (and the modules it would
> clash with) is a clear wart due to lacking appropriate type classes
> for collections. You probably shouldn't use that to support your
> point.

That's an interesting point. However, I don't believe that there is an
elegant solution to e.g. unify Map.insert and Set.insert using an
advanced type class. I often see people trying to resolve name conflicts
by type classes, often indicated by FlexibleInstances. I think this in
turn is abuse. It is certainly ok to use (<>) for different types via
the Monoid class, but already this one is difficult, because for Maps
there are different sensible implementations.

That is, we won't get rid from names with module dependend types, we
cannot and should not resolve every conflict using type classes. There
are many cases where the module system is the better tool than advanced
type hacks.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method

Edward Kmett-2
In reply to this post by Ian Lynagh
Note: at least for Integer, allBits / oneBits is also definable, despite note being Finite


On Mon, Feb 24, 2014 at 4:12 PM, Ian Lynagh <[hidden email]> wrote:
On Sat, Feb 22, 2014 at 02:51:24PM -0500, Anthony Cowley wrote:
> I am -1 on the name zero. I don't think importing Data.Bits unqualified is uncommon at all, and zero is prime naming real estate. I am +0.5 on the addition overall, as most uses of Bits are with types that also have Num instances.

For those that don't have a Num instance, "zero" may not make as much
sense.

Perhaps something like noBits would be better. And FiniteBits may also
want an allBits?


Thanks
Ian

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method

Gershom Bazerman
The issue isn't about qualified or unqualified names at all. It is about names which express intent clearly and evocatively, and names which are unacceptably ambiguous.

As such, I propose

zero --> whereDidTheBitsGo

and conversely,

allBits --> iHaveAllTheBits

It seems to me that these are expressive names with unmistakable meanings.

-G

On 2/24/14, 5:00 PM, Edward Kmett wrote:
Note: at least for Integer, allBits / oneBits is also definable, despite note being Finite


On Mon, Feb 24, 2014 at 4:12 PM, Ian Lynagh <[hidden email]> wrote:
On Sat, Feb 22, 2014 at 02:51:24PM -0500, Anthony Cowley wrote:
> I am -1 on the name zero. I don't think importing Data.Bits unqualified is uncommon at all, and zero is prime naming real estate. I am +0.5 on the addition overall, as most uses of Bits are with types that also have Num instances.

For those that don't have a Num instance, "zero" may not make as much
sense.

Perhaps something like noBits would be better. And FiniteBits may also
want an allBits?


Thanks
Ian

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Michael Snoyman
In reply to this post by Henning Thielemann-4



On Mon, Feb 24, 2014 at 10:30 PM, Henning Thielemann <[hidden email]> wrote:
Am <a href="tel:24.02.2014%2020" value="+12402201420" target="_blank">24.02.2014 20:56, schrieb Edward Kmett:

As far as I know the only serious proponent of using qualified imports
for all imports /all/ the time is you.

First, there are some important packages like containers and bytestring that clearly are intended for qualified imports, and I really like that insertFM was replaced by Map.insert in the past. Second, your argument addresses a person not the issue.

Name conflicts don't affect you. We get that. We got that loud and clear
virtually every time the naming of pretty much anything has arisen on
this mailing list for the last few years.

Sure, because there is no general discussion about the pros and cons of various naming styles. That's why it is discussed for every single identifier. How should a general discussion look like? What could be its outcome? That I am no longer allowed to propose the qualified import style?

That doesn't change the fact that your practice and common practice diverge.

And I challenge the common practice, because it prefers convenience for few package authors over convenience for many package user (that may not even be a Haskell programmer).

For an example let me look at your lens package. You use unqualified and implicit imports. That is according to the PVP you would need to use tight version bounds like "containers >=0.4.0 && <0.5.0.1", but you don't. That is, your package does not conform to the PVP. It implies that users may have to fix your package when one of the imported packages starts to export identifiers that clash with those from "lens". Of course, there is no need to conform to the PVP. But it works best if many people adhere to it.

I have not written the PVP, that is, there must be at least one other person who cares. I understand the need for it and try to comply to it. Maybe I am in a minority. Looking at Hackage it seems I am in a minority. But I believe I am in the minority who cares whether packages work together. Shall I capitulate to the majority which does not seem to care about package interoperability?

I am also ok if sloppy common practice happens in many Hackage packages. I do not need to use them. But I need to use 'base'.


This email seems to conflate a number of different issues together. I'd like to address them separately.

Firstly, regarding naming style. As I see it, there are essentially three camps on this one:

1. Short names that are intended to be imported qualified. Examples: Data.Map, Data.ByteString.
2. Longer names that can be imported unqualified. Examples: Data.IORef, Control.Concurrent.MVar.
3. Typeclass-based approaches that generalize across multiple libraries. Examples: Data.Foldable, Data.Traversable.

The initial discussion came down to an argument between (1) and (2). What I disagree in your email Henning is the implication that this "sloppy practice" in base will somehow negatively affect you. As I see it, the sum total of negative effect is that you'll be required to type a few extra characters (e.g., zeroBits instead of zero). Am I missing something? Given that (a) a huge amount of base already works this way, (b) having the longer name will allow the unqualified import approach, and (c) it has a small impact on those wanting unqualified imports, I'd come down with a strong vote in favor of option (2).

Next is the issue of PVP. I am someone who has stopped religiously following the PVP in the past few years. Your email seems to imply that only those following the PVP care about making sure that "packages work together." I disagree here; I don't use the PVP specifically because I care about package interoperability.

The point of the PVP is to ensure that code builds. It's a purely compile-time concept. The PVP solves the problem of an update to a dependency causing a downstream package to break. And assuming everyone adheres to it[1], it ensures that cabal will never try to perform a build which isn't guaranteed to work.

But that's only one half of the "package interoperability" issue. I face this first hand on a daily basis with my Stackage maintenance. I spend far more time reporting issues of restrictive upper bounds than I do with broken builds from upstream changes. So I look at this as purely a game of statistics: are you more likely to have code break because version 1.2 of text changes the type of the map function and you didn't have an upper bound, or because two dependencies of yours have *conflicting* versions bounds on a package like aeson[2]? In my experience, the latter occurs far more often than the former.

My point here is: please don't try to frame this argument as "sloppy people who hate compatibility" versus "PVP-adhering people who make Hackage better." Some of us who have stopped following the PVP have done so for very principled reasons, even if you disagree with them. (And Edward's comments on maintenance effort is not to be ignored either.)

Three final points:

* I know that back in the base 3/4 transition there was good reason for upper bounds on base. Today, it makes almost no sense: it simply prevents cabal from even *trying* to perform a compilation. Same goes with libraries like array and template-haskell, which make up most of the issue with testing of GHC 7.8 Stackage builds[3]. Can any PVP proponent explain why these upper bounds still help us on corelibs?
* If you're concerned about your production code base breaking by changes on Hackage, you're doing it wrong. Basing your entire production build on the presumption that Hackage maintainers perfectly follow the PVP and never make any mistakes in new releases of their packages is a recipe for disaster. You should be pinning down the exact versions of packages you depend on. Greg Weber described a technique for this[4].
* The PVP doesn't in any way solve all problems. You can perfectly adhere to the PVP and still experience breakage. I've seen a number of examples of this in the past, mostly to do with the fact that you don't lock down the versions of transitive dependencies, which can cause re-exports to include new functions or expose (or hide) typeclass instances.

Michael

[1] And never makes any mistakes of course.
[2] This just occurred in Stackage.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Sven Panne-2
In reply to this post by Henning Thielemann-4
2014-02-24 21:30 GMT+01:00 Henning Thielemann
<[hidden email]>:
> [...] You use unqualified and
> implicit imports. That is according to the PVP you would need to use tight
> version bounds like "containers >=0.4.0 && <0.5.0.1", but you don't. That
> is, your package does not conform to the PVP. [...]

o_O Dumb question: Can somebody please explain why this doesn't
conform to the PVP? I have a very hard time reading that out of
http://www.haskell.org/haskellwiki/Package_versioning_policy. Perhaps
I'm looking at the wrong document or this interpretation is just
wishful thinking...

Regarding upper bounds: I never understood what their advantage should
be, IMHO they only lead to a version hell where you can't compile your
stuff anymore *only* because of the bounds, not because of anything
else.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Daniel Trstenjak-2
In reply to this post by Michael Snoyman

Hi Michael,

> (b) having the longer name will allow the unqualified import approach ...

The longer name just reduces the possibility of conflicts, which might
be already sufficient and in the case of 'zeroBits' it might be really
the right thing.

I think the point of proponents of qualified imports is, that by having
'Bits.zero' instead of 'zeroBits' you're typing almost the same amount
of characters, but the first solution is safer.

I don't think that anybody would like to write 'Bits.zeroBits', sure you
could still explicitly import 'zeroBits' and still have the same safety,
but then you have more work with the imports, and at the end nobody
wants to do more work and this seems to be the common ground of users
and non users of qualified imports ;).

> But that's only one half of the "package interoperability" issue. I face this
> first hand on a daily basis with my Stackage maintenance. I spend far more time
> reporting issues of restrictive upper bounds than I do with broken builds from
> upstream changes. So I look at this as purely a game of statistics: are you
> more likely to have code break because version 1.2 of text changes the type of
> the map function and you didn't have an upper bound, or because two
> dependencies of yours have *conflicting* versions bounds on a package like
> aeson[2]? In my experience, the latter occurs far more often than the former.

I mostly came to the conclusion, that the PVP is perfectly fine for
binaries/executables, especially in conjunction with a cabal sandbox,
but in a lot of cases annoying for libraries.


Greetings,
Daniel
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
12345 ... 8