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

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

Re: Proposal: add new Data.Bits.Bits(bitZero) method (was: Proposal: Explicitly require "Data.Bits.bit (-1) == 0" property)

Edward Kmett-2
I like those laws insofar as they go.

It'd be nice to sit down and specify the rest of the Data.Bits laws some day. (Not volunteering!)

-Edward


On Wed, Feb 26, 2014 at 8:30 PM, wren ng thornton <[hidden email]> wrote:
I'm +1 for the following slightly extended proposal:

* add zeroBits
* with default implementation: clearBit (bit 0) 0
* and requiring the following laws for all n valid for the type:
    * clearBit zeroBits n == zeroBits
    * setBit zeroBits n == bit n
    * testBit zeroBits n == False
    * popCount zeroBits == 0

--
Live well,
~wren
_______________________________________________
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)

Greg Weber
In reply to this post by Carter Schonwald
That was the plan. I spend a large amount of company time contributing back to open source. Originally I was going to spend some of it on helping implement cabal freeze, but I left it in the hands of others that were more capable and I haven't checked back in a long time. 


On Thu, Feb 27, 2014 at 1:00 PM, Carter Schonwald <[hidden email]> wrote:
cool, so is docmunch going to allocate some money or manpower to help out? :)


On Thu, Feb 27, 2014 at 3:36 PM, Greg Weber <[hidden email]> wrote:



On Thu, Feb 27, 2014 at 9:35 AM, Austin Seipp <[hidden email]> wrote:
Hi Greg,

On Thu, Feb 27, 2014 at 10:30 AM, Greg Weber <[hidden email]> wrote:
> I actually think work on the a) cabal solver has been a distraction from
> more pressing issues: the need for sandboxes (that is done now) and
> reproducible builds (frozen dependencies). If you look at Ruby's Bundler,
> which has been extremely successful, it has historically (maybe they have a
> better solver now) been a dumb tool in terms of its solver that works
> extremely well. I think 90+% of this conversation is pretty wasteful,
> because once we have reproducible builds everything is going to change. If
> the energy could be re-directed to being able to create reproducible builds
> in Haskell, then we could figure out what the next most important priority
> is.

I'd like to carefully point out however, that it is not a zero-sum
game - work dedicated to improving the constraint solver is not work
which is implicitly taken away any other set of tools - like a
'freeze' command. There is no 'distraction' IMO - it is a set of
individuals (or companies, even) each with their own priorities. I
think this is the sign of a healthy community, actually - one that
places importance on its tools and seeks to find optimal ways to
improve them in a variety of ways. A freeze command and an improved
solver are both excellent (and worthy) improvements.

I agree that it is not zero sum, but I do think that at some point the wrong priorities must have been chosen since I have to go to special effort to produce a consistent build. Also this is all getting mixed up with a lot of talk about PVP and other things whose relevance changes if the underlying installation machinery supports what every application developer should be doing.


In reality, bundler works precisely for the reason you said it did: it
avoids all the actually difficult problems. But that comes at a cost,
because Bundler for example can't actually tell me when things *are*
going to break. If I bump my dependencies, create a new Gemfile lock,
and test - it could all simply explode later on at runtime, even if it
could have been concluded from the constraints that it was all invalid
in the first place. The only thing bundler buys me is that this
explosion won't potentially extend to the rest of my global
environment when it happens. Which is a good thing, truth be told, and
why it is so popular - otherwise this happens constantly.

This wasn't my experience using bundler. Bundler supports conservative upgrades that create consistent packages. So if you want to upgrade something you place a range on it and ask Bundler to upgrade it. I don't doubt though that it may let you manually subvert the system.


These two concerns are, as far as I can see, in no way opposed in
spirit or practice, and suggesting one is essentially wasted effort
that distracts people - when I see no evidence of that - strikes me as
odd.


I think the industrial Haskell group supported work on a better solver, which was definitely helpful, but I just think it would have been wiser to support work on consistent builds first. I agree that they can be worked on independently.



_______________________________________________
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)

Carter Schonwald
cool! :)



On Thu, Feb 27, 2014 at 10:17 PM, Greg Weber <[hidden email]> wrote:
That was the plan. I spend a large amount of company time contributing back to open source. Originally I was going to spend some of it on helping implement cabal freeze, but I left it in the hands of others that were more capable and I haven't checked back in a long time. 


On Thu, Feb 27, 2014 at 1:00 PM, Carter Schonwald <[hidden email]> wrote:
cool, so is docmunch going to allocate some money or manpower to help out? :)


On Thu, Feb 27, 2014 at 3:36 PM, Greg Weber <[hidden email]> wrote:



On Thu, Feb 27, 2014 at 9:35 AM, Austin Seipp <[hidden email]> wrote:
Hi Greg,

On Thu, Feb 27, 2014 at 10:30 AM, Greg Weber <[hidden email]> wrote:
> I actually think work on the a) cabal solver has been a distraction from
> more pressing issues: the need for sandboxes (that is done now) and
> reproducible builds (frozen dependencies). If you look at Ruby's Bundler,
> which has been extremely successful, it has historically (maybe they have a
> better solver now) been a dumb tool in terms of its solver that works
> extremely well. I think 90+% of this conversation is pretty wasteful,
> because once we have reproducible builds everything is going to change. If
> the energy could be re-directed to being able to create reproducible builds
> in Haskell, then we could figure out what the next most important priority
> is.

I'd like to carefully point out however, that it is not a zero-sum
game - work dedicated to improving the constraint solver is not work
which is implicitly taken away any other set of tools - like a
'freeze' command. There is no 'distraction' IMO - it is a set of
individuals (or companies, even) each with their own priorities. I
think this is the sign of a healthy community, actually - one that
places importance on its tools and seeks to find optimal ways to
improve them in a variety of ways. A freeze command and an improved
solver are both excellent (and worthy) improvements.

I agree that it is not zero sum, but I do think that at some point the wrong priorities must have been chosen since I have to go to special effort to produce a consistent build. Also this is all getting mixed up with a lot of talk about PVP and other things whose relevance changes if the underlying installation machinery supports what every application developer should be doing.


In reality, bundler works precisely for the reason you said it did: it
avoids all the actually difficult problems. But that comes at a cost,
because Bundler for example can't actually tell me when things *are*
going to break. If I bump my dependencies, create a new Gemfile lock,
and test - it could all simply explode later on at runtime, even if it
could have been concluded from the constraints that it was all invalid
in the first place. The only thing bundler buys me is that this
explosion won't potentially extend to the rest of my global
environment when it happens. Which is a good thing, truth be told, and
why it is so popular - otherwise this happens constantly.

This wasn't my experience using bundler. Bundler supports conservative upgrades that create consistent packages. So if you want to upgrade something you place a range on it and ask Bundler to upgrade it. I don't doubt though that it may let you manually subvert the system.


These two concerns are, as far as I can see, in no way opposed in
spirit or practice, and suggesting one is essentially wasted effort
that distracts people - when I see no evidence of that - strikes me as
odd.


I think the industrial Haskell group supported work on a better solver, which was definitely helpful, but I just think it would have been wiser to support work on consistent builds first. I agree that they can be worked on independently.




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

Re: Proposal: add new Data.Bits.Bits(bitZero) method

Herbert Valerio Riedel
In reply to this post by Edward Kmett-2

Fyi, here's a draft patch:

 https://github.com/hvr/packages-base/commit/03c015951a385533b9f419863c37b7df1f791190

feel free to comment on the patch (by annotating on GitHub, or
discussing it here), as this is what I'll probably push to GHC HEAD
after the deadline.

Note: I still have to go over the existing Bits instances, to see if GHC
is properly inlining/constant-folding 'clearBit (bit 0) 0' with the
default-impl, or if I need to add a couple of 'zeroBits = 0' to the
instances in `base`.

On 2014-02-27 at 22:39:27 +0100, Edward Kmett wrote:

> I like those laws insofar as they go.
>
> It'd be nice to sit down and specify the rest of the Data.Bits laws some
> day. (Not volunteering!)
>
> -Edward
>
>
> On Wed, Feb 26, 2014 at 8:30 PM, wren ng thornton
> <[hidden email]>wrote:
>
>> I'm +1 for the following slightly extended proposal:
>>
>> * add zeroBits
>> * with default implementation: clearBit (bit 0) 0
>> * and requiring the following laws for all n valid for the type:
>>     * clearBit zeroBits n == zeroBits
>>     * setBit zeroBits n == bit n
>>     * testBit zeroBits n == False
>>     * popCount zeroBits == 0
>>
>> --
>> Live well,
>> ~wren
>> _______________________________________________
>> Libraries mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/libraries
>>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries

--
"Elegance is not optional" -- Richard O'Keefe
_______________________________________________
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 Edward Kmett-2
I got distracted by writing a tool that checks consistency of package
dependencies and import styles. It's not yet perfect, but usable:

https://hackage.haskell.org/package/check-pvp


Description:
   Check whether the version ranges used in the @Build-Depends@ field
   matches the style of module imports
   according to the Package Versioning Policy (PVP).
   See <http://www.haskell.org/haskellwiki/Package_versioning_policy>.
   The tool essentially looks for any dependency
   like @containers >=0.5 && <0.6@
   that allows the addition of identifiers to modules
   within the version range.
   Then it checks whether all module imports from @containers@
   are protected against name clashes
   that could be caused by addition of identifiers.
   .
   You must run the tool in a directory containing a Cabal package.
   .
   > $ check-pvp
   .
   This requires that the package is configured,
   since only then the association of packages to modules is known.
   If you want to run the tool on a non-configured package
   you may just check all imports for addition-proof style.
   .
   > $ check-pvp --include-all
   .
   It follows a detailed description of the procedure
   and the rationale behind it.
   .
   First the program classifies all dependencies
   in the Cabal file of the package.
   You can show all classifications with the @--classify-dependencies@
option,
   otherwise only problematic dependencies are shown.
   .
   A dependency like @containers >=0.5.0.3 && <0.5.1@
   does not allow changes of the API of @containers@
   and thus the program does not check its imports.
   Clashing import abbreviations are an exception.
   .
   The dependency @containers >=0.5.1 && <0.6@
   requires more care when importing modules from @containers@
   and this is what the program is going to check next.
   This is the main purpose of the program!
   I warmly recommend this kind of dependency range
   since it greatly reduces the work
   to keep your package going together with its imported packages.
   .
   Dependencies like @containers >=0.5@ or @containers >=0.5 && <1@
   are always problematic,
   since within the specified version ranges identifier can disappear.
   There is no import style that protects against removed identifiers.
   .
   An inclusive upper bound as in @containers >=0.5 && <=0.6@
   will also cause a warning, because it is unnecessarily strict.
   If you know that @containers-0.6@ works for you,
   then @containers-0.6.0.1@ or @containers-0.6.1@ will also work,
   depending on your import style.
   A special case of inclusive upper bounds are specific versions
   like in @containers ==0.6@.
   The argument for the warning remains the same.
   .
   Please note that the check of ranges
   is performed entirely on the package description.
   The program will not inspect the imported module contents.
   E.g. if you depend on @containers >=0.5 && <0.6@
   but import in a way that risks name clashes,
   then you may just extend the dependency to @containers >=0.5 && <0.6.1@
   in order to let the checker fall silent.
   If you use the dependency @containers >=0.5 && <0.6.1@
   then the checker expects that you have verified
   that your package works with all versions of kind @0.5.x@
   and the version @0.6.0@.
   Other versions would then work, too,
   due to the constraints imposed by package versioning policy.
   .
   Let us now look at imports
   that must be protected against identifier additions.
   .
   The program may complain about a lax import.
   This means you have imported like
   .
   > import Data.Map as Map
   .
   Additions to @Data.Map@ may clash with other identifiers,
   thus you must import either
   .
   > import qualified Data.Map as Map
   .
   or
   .
   > import Data.Map (Map)
   .
   The program may complain about an open list of constructors as in
   .
   > import Data.Sequence (ViewL(..))
   .
   Additions of constructors to @ViewL@ may also conflict with other
identifiers.
   You must instead import like
   .
   > import Data.Sequence (ViewL(EmptyL, (:<)))
   .
   or
   .
   > import qualified Data.Sequence as Seq
   .
   The program emits an error on clashing module abbreviations like
   .
   > import qualified Data.Map.Lazy as Map
   > import qualified Data.Map.Strict as Map
   .
   This error is raised
   whenever multiple modules are imported with the same abbreviation,
   where at least one module is open for additions.
   Our test is overly strict in the sense that it also blames
   .
   > import qualified Data.Map as Map
   > import qualified Data.Map as Map
   .
   but I think it is good idea to avoid redundant imports anyway.
   .
   Additionally you can enable a test for hiding imports
   with the @--pedantic@ option.
   The import
   .
   > import Data.Map hiding (insert)
   .
   is not bad in the sense of the PVP,
   but this way you depend on the existence of the identifier @insert@
   although you do not need it.
   If it is removed in a later version of @containers@,
   then your import breaks although you did not use the identifier.
   .
   Finally you can control what items are checked.
   First of all you can select the imports that are checked.
   Normally the imports are checked that belong to lax dependencies
   like @containers >=0.5 && <0.6@.
   However this requires the package to be configured
   in order to know which import belongs to which dependency.
   E.g. @Data.Map@ belongs to @containers@.
   You can just check all imports for being addition-proof
   using the @--include-all@ option.
   Following you can write the options
   @--include-import@,
   @--exclude-import@,
   @--include-dependency@,
   @--exclude-dependency@
   that allow to additionally check or ignore imports
   from certain modules or packages.
   These modifiers are applied from left to right.
   E.g. @--exclude-import=Prelude@ will accept any import style for
@Prelude@
   and @--exclude-dependency=foobar@ will ignore the package @foobar@,
   say, because it does not conform to the PVP.
   .
   Secondly, you may ignore certain modules or components of the package
   using the options
   @--exclude-module@,
   @--exclude-library@,
   @--exclude-executables@,
   @--exclude-testsuites@,
   @--exclude-benchmarks@.
   E.g. @--exclude-module=Paths_PKG@ will exclude the Paths module
   that is generated by Cabal.
   I assume that it will always be free of name clashes.
   .
   Known problems:
   .
   * The program cannot automatically filter out the @Paths@ module.
   .
   * The program cannot find and check preprocessed modules.
   .
   * The program may yield wrong results in the presence of Cabal
conditions.
   .
   If this program proves to be useful
   it might eventually be integrated in the @check@ command of
@cabal-install@.
   See <https://github.com/haskell/cabal/issues/1703>.
   .
   Alternative:
   If you want to allow exclusively large version ranges, i.e. @>=x.y &&
<x.y+1@,
   then you may also add the option @-fwarn-missing-import-lists@
   to the @GHC-Options@ fields of your Cabal file.
   See <https://ghc.haskell.org/trac/ghc/ticket/4977>.
   Unfortunately there is no GHC warning on clashing module abbreviations.
   See <https://ghc.haskell.org/trac/ghc/ticket/4980>.

_______________________________________________
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
I just want to say thank you for writing this tool.

I may not agree with your interpretation of the PVP on this particular issue, and will probably only use it on a couple of smaller packages that have almost no imports, but at least putting code out there to help those who do want to work in that style is a very helpful and valuable thing.

-Edward


On Fri, Feb 28, 2014 at 3:10 PM, Henning Thielemann <[hidden email]> wrote:
I got distracted by writing a tool that checks consistency of package dependencies and import styles. It's not yet perfect, but usable:

https://hackage.haskell.org/package/check-pvp


Description:
  Check whether the version ranges used in the @Build-Depends@ field
  matches the style of module imports
  according to the Package Versioning Policy (PVP).
  See <http://www.haskell.org/haskellwiki/Package_versioning_policy>.
  The tool essentially looks for any dependency
  like @containers >=0.5 && <0.6@
  that allows the addition of identifiers to modules
  within the version range.
  Then it checks whether all module imports from @containers@
  are protected against name clashes
  that could be caused by addition of identifiers.
  .
  You must run the tool in a directory containing a Cabal package.
  .
  > $ check-pvp
  .
  This requires that the package is configured,
  since only then the association of packages to modules is known.
  If you want to run the tool on a non-configured package
  you may just check all imports for addition-proof style.
  .
  > $ check-pvp --include-all
  .
  It follows a detailed description of the procedure
  and the rationale behind it.
  .
  First the program classifies all dependencies
  in the Cabal file of the package.
  You can show all classifications with the @--classify-dependencies@ option,
  otherwise only problematic dependencies are shown.
  .
  A dependency like @containers >=0.5.0.3 && <0.5.1@
  does not allow changes of the API of @containers@
  and thus the program does not check its imports.
  Clashing import abbreviations are an exception.
  .
  The dependency @containers >=0.5.1 && <0.6@
  requires more care when importing modules from @containers@
  and this is what the program is going to check next.
  This is the main purpose of the program!
  I warmly recommend this kind of dependency range
  since it greatly reduces the work
  to keep your package going together with its imported packages.
  .
  Dependencies like @containers >=0.5@ or @containers >=0.5 && <1@
  are always problematic,
  since within the specified version ranges identifier can disappear.
  There is no import style that protects against removed identifiers.
  .
  An inclusive upper bound as in @containers >=0.5 && <=0.6@
  will also cause a warning, because it is unnecessarily strict.
  If you know that @containers-0.6@ works for you,
  then @containers-0.6.0.1@ or @containers-0.6.1@ will also work,
  depending on your import style.
  A special case of inclusive upper bounds are specific versions
  like in @containers ==0.6@.
  The argument for the warning remains the same.
  .
  Please note that the check of ranges
  is performed entirely on the package description.
  The program will not inspect the imported module contents.
  E.g. if you depend on @containers >=0.5 && <0.6@
  but import in a way that risks name clashes,
  then you may just extend the dependency to @containers >=0.5 && <0.6.1@
  in order to let the checker fall silent.
  If you use the dependency @containers >=0.5 && <0.6.1@
  then the checker expects that you have verified
  that your package works with all versions of kind @0.5.x@
  and the version @0.6.0@.
  Other versions would then work, too,
  due to the constraints imposed by package versioning policy.
  .
  Let us now look at imports
  that must be protected against identifier additions.
  .
  The program may complain about a lax import.
  This means you have imported like
  .
  > import Data.Map as Map
  .
  Additions to @Data.Map@ may clash with other identifiers,
  thus you must import either
  .
  > import qualified Data.Map as Map
  .
  or
  .
  > import Data.Map (Map)
  .
  The program may complain about an open list of constructors as in
  .
  > import Data.Sequence (ViewL(..))
  .
  Additions of constructors to @ViewL@ may also conflict with other identifiers.
  You must instead import like
  .
  > import Data.Sequence (ViewL(EmptyL, (:<)))
  .
  or
  .
  > import qualified Data.Sequence as Seq
  .
  The program emits an error on clashing module abbreviations like
  .
  > import qualified Data.Map.Lazy as Map
  > import qualified Data.Map.Strict as Map
  .
  This error is raised
  whenever multiple modules are imported with the same abbreviation,
  where at least one module is open for additions.
  Our test is overly strict in the sense that it also blames
  .
  > import qualified Data.Map as Map
  > import qualified Data.Map as Map
  .
  but I think it is good idea to avoid redundant imports anyway.
  .
  Additionally you can enable a test for hiding imports
  with the @--pedantic@ option.
  The import
  .
  > import Data.Map hiding (insert)
  .
  is not bad in the sense of the PVP,
  but this way you depend on the existence of the identifier @insert@
  although you do not need it.
  If it is removed in a later version of @containers@,
  then your import breaks although you did not use the identifier.
  .
  Finally you can control what items are checked.
  First of all you can select the imports that are checked.
  Normally the imports are checked that belong to lax dependencies
  like @containers >=0.5 && <0.6@.
  However this requires the package to be configured
  in order to know which import belongs to which dependency.
  E.g. @Data.Map@ belongs to @containers@.
  You can just check all imports for being addition-proof
  using the @--include-all@ option.
  Following you can write the options
  @--include-import@,
  @--exclude-import@,
  @--include-dependency@,
  @--exclude-dependency@
  that allow to additionally check or ignore imports
  from certain modules or packages.
  These modifiers are applied from left to right.
  E.g. @--exclude-import=Prelude@ will accept any import style for @Prelude@
  and @--exclude-dependency=foobar@ will ignore the package @foobar@,
  say, because it does not conform to the PVP.
  .
  Secondly, you may ignore certain modules or components of the package
  using the options
  @--exclude-module@,
  @--exclude-library@,
  @--exclude-executables@,
  @--exclude-testsuites@,
  @--exclude-benchmarks@.
  E.g. @--exclude-module=Paths_PKG@ will exclude the Paths module
  that is generated by Cabal.
  I assume that it will always be free of name clashes.
  .
  Known problems:
  .
  * The program cannot automatically filter out the @Paths@ module.
  .
  * The program cannot find and check preprocessed modules.
  .
  * The program may yield wrong results in the presence of Cabal conditions.
  .
  If this program proves to be useful
  it might eventually be integrated in the @check@ command of @cabal-install@.
  See <https://github.com/haskell/cabal/issues/1703>.
  .
  Alternative:
  If you want to allow exclusively large version ranges, i.e. @>=x.y && <x.y+1@,
  then you may also add the option @-fwarn-missing-import-lists@
  to the @GHC-Options@ fields of your Cabal file.
  See <https://ghc.haskell.org/trac/ghc/ticket/4977>.
  Unfortunately there is no GHC warning on clashing module abbreviations.
  See <https://ghc.haskell.org/trac/ghc/ticket/4980>.


_______________________________________________
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 -> check-pvp

Henning Thielemann-4
In reply to this post by Henning Thielemann-4
Am 28.02.2014 21:10, schrieb Henning Thielemann:
> I got distracted by writing a tool that checks consistency of package
> dependencies and import styles. It's not yet perfect, but usable:
>
> https://hackage.haskell.org/package/check-pvp
>
>
> Description:
 > ...
>    The program may complain about an open list of constructors as in
>    .
>    > import Data.Sequence (ViewL(..))
>    .
>    Additions of constructors to @ViewL@ may also conflict with other
> identifiers.

Maybe I am too strict here. The PVP considers additions of constructors
and class methods as changes, not additions. That is, we don't need to
fear additions of constructor and methods within the range >=x.y &&
<x.y+1. I may turn this test into "pedantic". I still prefer explicit
constructor import lists, since they allow the reader to easily track
the origin of an identifier - especially if it is gone.

_______________________________________________
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)

Carter Schonwald
In reply to this post by Edward Kmett-2
I second that sentiment of appreciation.  As much as we all disagree on some things, we all agree you make a tremendous amount of neat code available to the community. 

On Friday, February 28, 2014, Edward Kmett <[hidden email]> wrote:
I just want to say thank you for writing this tool.

I may not agree with your interpretation of the PVP on this particular issue, and will probably only use it on a couple of smaller packages that have almost no imports, but at least putting code out there to help those who do want to work in that style is a very helpful and valuable thing.

-Edward


On Fri, Feb 28, 2014 at 3:10 PM, Henning Thielemann <[hidden email]> wrote:
I got distracted by writing a tool that checks consistency of package dependencies and import styles. It's not yet perfect, but usable:

https://hackage.haskell.org/package/check-pvp


Description:
  Check whether the version ranges used in the @Build-Depends@ field
  matches the style of module imports
  according to the Package Versioning Policy (PVP).
  See <http://www.haskell.org/haskellwiki/Package_versioning_policy>.
  The tool essentially looks for any dependency
  like @containers >=0.5 && <0.6@
  that allows the addition of identifiers to modules
  within the version range.
  Then it checks whether all module imports from @containers@
  are protected against name clashes
  that could be caused by addition of identifiers.
  .
  You must run the tool in a directory containing a Cabal package.
  .
  > $ check-pvp
  .
  This requires that the package is configured,
  since only then the association of packages to modules is known.
  If you want to run the tool on a non-configured package
  you may just check all imports for addition-proof style.
  .
  > $ check-pvp --include-all
  .
  It follows a detailed description of the procedure
  and the rationale behind it.
  .
  First the program classifies all dependencies
  in the Cabal file of the package.
  You can show all classifications with the @--classify-dependencies@ option,
  otherwise only problematic dependencies are shown.
  .
  A dependency like @containers >=0.5.0.3 && <0.5.1@
  does not allow changes of the API of @containers@
  and thus the program does not check its imports.
  Clashing import abbreviations are an exception.
  .
  The dependency @containers >=0.5.1 && <0.6@
  requires more care when importing modules from @containers@
  and this is what the program is going to check next.
  This is the main purpose of the program!
  I warmly recommend this kind of dependency range
  since it greatly reduces the work
  to keep your package going together with its imported packages.
  .
  Dependencies like @containers >=0.5@ or @containers >=0.5 && <1@
  are always problematic,
  since within the specified version ranges identifier can disappear.
  There is no import style that protects against removed identifiers.
  .
  An inclusive upper bound as in @containers >=0.5 && <=0.6@
  will also cause a warning, because it is unnecessarily strict.
  If you know that @containers-0.6@ works for you,
  then @containers-0.6.0.1@ or @containers-0.6.1@ will also work,
  depending on your import style.
  A special case of inclusive upper bounds are specific versions
  like in @containers ==0.6@.
  The argument for the warning remains the same.
  .
  Please note that the check of ranges
  is performed entirely on the package description.
  The program will not inspect the imported module contents.
  E.g. if you depend on @containers >=0.5 && <0.6@
  but import in a way that risks name clashes,
  then you may just extend the dependency to @containers >=0.5 && <0.6.1@
  in order to let the checker fall silent.
  If you use the dependency @containers >=0.5 && <0.6.1@
  then the checker expects that you have verified
  that your package works with all versions of kind @0.5.x@
  and the version @0.6.0@.
  Other versions would then work, too,
  due to the constraints imposed by package versioning policy.
  .
  Let us now look at imports
  that must be protected against identifier additions.
  .
  The program may complain about a lax import.
  This means you have imported like
  .
  > import Data.Map as Map
  .
  Additions to @Data.Map@ may clash with other identifiers,
  thus you must import either
  .
  > import qualified Data.Map as Map
  .
  or
  .
  > import Data.Map (Map)
  .
  The program may complain about an open list of constructors as in
  .
  > import Data.Sequence (ViewL(..))
  .
  Additions of constructors to @ViewL@ may also conflict with other identifiers.
  You must instead import like
  .
  > import Data.Sequence (ViewL(Empt

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

[Final Summary] Proposal: add new Data.Bits.Bits(bitZero) method

Herbert Valerio Riedel
In reply to this post by Herbert Valerio Riedel
On 2014-02-22 at 11:03:12 +0100, Herbert Valerio Riedel wrote:

> Here's the result of the proposal
>
>>> Introduce a new class method
>>>
>>>   class Bits a where
>>>       ...
>>>       -- | Value with all bits cleared
>>>       <0-value-method> :: a
>>>       ...
>>>
>>> modulo naming of '<0-value-method>'

Unless I missed any votes, the current tally stands at

for `Bits.zero`

 - ARJANEN Loïc Jean David
 - Henning Thielemann
 - Herbert Valerio Riedel (+0.99)

for 'Data.Bits.zeroBits'

 - Edward Kmett
 - Eric Mertens
 - Herbert Valerio Riedel
 - Twan van Laarhoven
 - (maybe?) ARJANEN Loïc Jean David
 - Anthony Cowley (+0.5)

This tilts the majority towards the name 'zeroBits'

As the proposal-deadline was close to the RC2 release, this made it into
GHC 7.8.1-RC2, and therefore GHC 7.8.1/base-4.7.0.0 will come with
`Data.Bits.zeroBits`[1]



Fwiw, there were some alternative names suggested, but those didn't gain
significant support:

  cleared, noBits, clearedBits, whereDidTheBitsGo, notOneBit, allZeroes

Beyond this proposal, it was hinted at that we might also want a name for
'complement zeroBits' (although that maybe a FiniteBits-instance), names
suggested for that were

  allBits, allOnes, oneBits, iHaveAllTheBits, everyLastBit

Cheers,
  hvr

 [1]: http://git.haskell.org/packages/base.git/commitdiff/147bca65bfac216bddff3ccde89409ca6323bb62
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
1 ... 5678