Hello *,
Right now, there seems to be no "defined" way to create a zero 'Bits'-value (w/o requiring also a 'Num' instance), that has all bits cleared without involving at least two operations from the 'Bits' class (e.g. `clearBit (bit 0) 0` or `let x = bit 0 in xor x x`). OTOH, introducing a new method 'class Bits a where bitZero :: a' seems overkill to me. However, "bit (-1)"[1] seems to result in just such a zero-value for all 'Bits' instances from base, so I'd hereby propose to simply document this as an expected property of 'bit', as well as the recommended way to introduce a zero-value (for when 'Num' is not available). Discussion period: 2 weeks [1]: ...or more generally 'bit n == 0' for n<0, as it's usually implemented as 'bit n = 1 shift n' _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
Am 16.02.2014 11:14, schrieb Herbert Valerio Riedel:
> Hello *, > > Right now, there seems to be no "defined" way to create a zero > 'Bits'-value (w/o requiring also a 'Num' instance), that has all bits > cleared without involving at least two operations from the 'Bits' class > (e.g. `clearBit (bit 0) 0` or `let x = bit 0 in xor x x`). > > OTOH, introducing a new method 'class Bits a where bitZero :: a' seems > overkill to me. > > However, "bit (-1)" It would be better to forbid "bit (-1)" by the type system, if this would be possible. If only indices would be allowed that actually exist, then we would have a nice law like "popCount (bit n) == 1". I would not like that the exceptional "bit (-1)" becomes the blessed way to create zeros. An additional "zero" method with a default implementation would be the clean way. _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Herbert Valerio Riedel
Hello,
I'll have to come down against that proposal because, at least on amd64 for 64 bits-sized types (Int, Int64, Word & Word64), it doesn't works. That's probably because bit n is usually implemented as 1 shifL n and that on this architechture, the arithmetic left-shift instruction takes only the shift count's 6 low-order bits into account. So we have bit (-1) = shiftL 1 (-1) = shiftL 1 63 = 2 ^ 63. I suspect the same may happen for 32 bits-sized types on x86 where only the 5 low order-bits of the shift count are considered. Regards, ARJANEN Loïc Le dimanche 16 février 2014, 11:14:12 Herbert Valerio Riedel a écrit : > Hello *, > > Right now, there seems to be no "defined" way to create a zero > 'Bits'-value (w/o requiring also a 'Num' instance), that has all bits > cleared without involving at least two operations from the 'Bits' class > (e.g. `clearBit (bit 0) 0` or `let x = bit 0 in xor x x`). > > OTOH, introducing a new method 'class Bits a where bitZero :: a' seems > overkill to me. > > However, "bit (-1)"[1] seems to result in just such a zero-value for all > 'Bits' instances from base, so I'd hereby propose to simply document > this as an expected property of 'bit', as well as the recommended way to > introduce a zero-value (for when 'Num' is not available). > > Discussion period: 2 weeks > > [1]: ...or more generally 'bit n == 0' for n<0, as it's usually > implemented as 'bit n = 1 shift n' Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
Hi,
On 2014-02-16 at 15:10:42 +0100, ARJANEN Loïc Jean David wrote: > I'll have to come down against that proposal because, at least on amd64 for 64 > bits-sized types (Int, Int64, Word & Word64), it doesn't works. You're right, I don't know how I could have missed that :-/ Since the presumed pre-condition for the proposal (that 'bit (-1) == 0' would already hold) I hereby amend the proposal to > Introduce a new class method > > class Bits a where > ... > -- | Value with all bits cleared > bitZero :: a > ... > > modulo naming of 'bitZero' (I'm hesitant to consume "zero" from the namespace as was suggested by Henning) _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Herbert Valerio Riedel
Nothing forbids you from allowing negative bit positions in a data type, for instance for fractional bits in a fixed position numeric type. Consequently, I'm -1 on this proposal.
You can currently construct 0 several ways, e.g. clearBit (bit 0) 0 could be use to supply a default for any such zeroBits member of the class. -Edward On Sun, Feb 16, 2014 at 5:14 AM, Herbert Valerio Riedel <[hidden email]> wrote: Hello *, _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Herbert Valerio Riedel
`bitZero` sounds like it should equal `bit 0`, which it doesn't. zeroBits ? -Edward On Sun, Feb 16, 2014 at 11:42 AM, Herbert Valerio Riedel <[hidden email]> wrote: Hi, _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Herbert Valerio Riedel
Am 16.02.2014 17:42, schrieb Herbert Valerio Riedel:
>> Introduce a new class method >> >> class Bits a where >> ... >> -- | Value with all bits cleared >> bitZero :: a >> ... >> >> modulo naming of 'bitZero' > > (I'm hesitant to consume "zero" from the namespace as was suggested by Henning) Let me defend "zero": Functions in the module that contain "Bit" in the name (clearBit, setBit, testBit) access a single bit. All functions that access many bits do not contain "Bit" (rotate, shift, xor, popCount). I propose to import the "zero" function with qualification, as well as the other functions from the module. I also propose to provide a default implementation of "zero", like "clearBit (bit 0) 0". This way, the "zero" method can be introduced without breaking existing code. _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Edward Kmett-2
The last time this topic came up (back when Num was split off) the discussion was derailed by the idea of a Bool class and then forgotten. I've hoped for an explicit zero element since then. +1 zeroBits On Feb 16, 2014 8:45 AM, "Edward Kmett" <[hidden email]> wrote:
_______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
Am 16.02.2014 17:51, schrieb Eric Mertens:
> The last time this topic came up (back when Num was split off) the > discussion was derailed by the idea of a Bool class and then forgotten. > I've hoped for an explicit zero element since then. I think it was this discussion: https://www.haskell.org/pipermail/libraries/2011-October/016919.html _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Henning Thielemann-4
Le dimanche 16 février 2014, 17:49:23 Henning Thielemann a écrit :
> Am 16.02.2014 17:42, schrieb Herbert Valerio Riedel: > >> Introduce a new class method > >> > >> class Bits a where > >> > >> ... > >> -- | Value with all bits cleared > >> bitZero :: a > >> ... > >> > >> modulo naming of 'bitZero' > > > > (I'm hesitant to consume "zero" from the namespace as was suggested by > > Henning) > Let me defend "zero": Functions in the module that contain "Bit" in the > name (clearBit, setBit, testBit) access a single bit. All functions that > access many bits do not contain "Bit" (rotate, shift, xor, popCount). I > propose to import the "zero" function with qualification, as well as the > other functions from the module. > > I also propose to provide a default implementation of "zero", like > "clearBit (bit 0) 0". This way, the "zero" method can be introduced > without breaking existing code. I'm in favour of that modified proposal, so +1 for a "zero" member of Bits. And if we fear problems with collisions, we could always name the member something like zeroValue or zeroBits. _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
Am 16.02.2014 19:16, schrieb ARJANEN Loïc Jean David:
> I'm in favour of that modified proposal, so +1 for a "zero" member of Bits. > > And if we fear problems with collisions, we could always name the member > something like zeroValue or zeroBits. If people adhere to the package versioning policy, then there cannot be collisions. That is, import Data.Bits requires strict version bounds (>=x.y.z.w && <x.y.z+1) and both of import Data.Bits (zero) import qualified Data.Bits as Bits allow lax version bounds (>=x.y.z && <x.y+1). Btw. "rotate" may already cause collisions with geometry libraries. _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Edward Kmett-2
+1 to `zeroBits`. The name fits in with `setBit` etc.
I'm also okay with the name `zero`. Twan On 16/02/14 17:45, Edward Kmett wrote: > `bitZero` sounds like it should equal `bit 0`, which it doesn't. > > zeroBits ? > > -Edward > > > On Sun, Feb 16, 2014 at 11:42 AM, Herbert Valerio Riedel <[hidden email] > <mailto:[hidden email]>> wrote: > > Hi, > > On 2014-02-16 at 15:10:42 +0100, ARJANEN Loïc Jean David wrote: > > I'll have to come down against that proposal because, at least on amd64 > for 64 > > bits-sized types (Int, Int64, Word & Word64), it doesn't works. > > You're right, I don't know how I could have missed that :-/ > > Since the presumed pre-condition for the proposal (that 'bit (-1) == 0' > would already hold) I hereby amend the proposal to > > > Introduce a new class method > > > > class Bits a where > > ... > > -- | Value with all bits cleared > > bitZero :: a > > ... > > > > modulo naming of 'bitZero' > > (I'm hesitant to consume "zero" from the namespace as was suggested by Henning) > _______________________________________________ > Libraries mailing list > [hidden email] <mailto:[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 |
In reply to this post by Herbert Valerio Riedel
Hello *,
Here's a mid-discussion summary 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>' from my point of view: - The idea came up already in 2011 when Num-superclass was to be removed from Bits (but discussion derailed) - So far general consensus (i.e. no "-1"s afaics) it's desired to have an all-bits-clear value introducing method in 'Bits' - Use "clearBit (bit 0) 0" as default implementation for smooth upgrade-path - Nameing for <0-value-method> boils down to two candidates: a) 'Data.Bits.zero' - based on the idea tha 'Data.Bits' ought to be imported qualified (or with explicit import-list) anyway (-> thus following PVP practice) - many existing Data.Bits.Bits methods such as 'rotate', 'complement', 'popCount', 'xor', or 'shift' don't have the name 'bit' in it (and those few that have, operate on single bits) - supporters (in no particular order): - ARJANEN Loïc Jean David - Henning Thielemann - Herbert Valerio Riedel (+0.99) - Twan van Laarhoven b) 'Data.Bits.zeroBits' - more verbose name reduces risk of namespace conflicts with unqualified imports - supporters (in no particular order): - Edward Kmett - Eric Mertens - Herbert Valerio Riedel - Twan van Laarhoven - (maybe?) ARJANEN Loïc Jean David 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'. Cheers, hvr _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
Zero is a big bit of name space. Id favor zerobits over zero.
On Saturday, February 22, 2014, Herbert Valerio Riedel <[hidden email]> wrote: Hello *, _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Herbert Valerio Riedel
I am notably strongly against taking 'zero' as it is much more appropriately used by more algebraic classes, and it is an annoyingly common name to take for such an often unqualified import. -Edward On Sat, Feb 22, 2014 at 5:03 AM, Herbert Valerio Riedel <[hidden email]> wrote: Hello *, _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Herbert Valerio Riedel
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. If we are naming this thing, then I vote for zeroBits.
Anthony > On Feb 22, 2014, at 5:03 AM, Herbert Valerio Riedel <[hidden email]> wrote: > > Hello *, > > Here's a mid-discussion summary 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>' > > from my point of view: > > - The idea came up already in 2011 when Num-superclass was to be removed from Bits > (but discussion derailed) > > - So far general consensus (i.e. no "-1"s afaics) it's desired to have > an all-bits-clear value introducing method in 'Bits' > > - Use "clearBit (bit 0) 0" as default implementation for smooth upgrade-path > > - Nameing for <0-value-method> boils down to two candidates: > > a) 'Data.Bits.zero' > > - based on the idea tha 'Data.Bits' ought to be imported > qualified (or with explicit import-list) anyway > (-> thus following PVP practice) > > - many existing Data.Bits.Bits methods such as 'rotate', > 'complement', 'popCount', 'xor', or 'shift' don't have > the name 'bit' in it (and those few that have, operate > on single bits) > > - supporters (in no particular order): > > - ARJANEN Loïc Jean David > - Henning Thielemann > - Herbert Valerio Riedel (+0.99) > - Twan van Laarhoven > > b) 'Data.Bits.zeroBits' > > - more verbose name reduces risk of namespace conflicts with unqualified imports > > - supporters (in no particular order): > > - Edward Kmett > - Eric Mertens > - Herbert Valerio Riedel > - Twan van Laarhoven > - (maybe?) ARJANEN Loïc Jean David > > > 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'. > > > Cheers, > hvr > _______________________________________________ > Libraries mailing list > [hidden email] > http://www.haskell.org/mailman/listinfo/libraries Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Carter Schonwald
Am 22.02.2014 15:56, schrieb Carter Schonwald:
> Zero is a big bit of name space. Id favor zerobits over zero. ... only if you plan to add another "zero" thing to the Data.Bits module. Conflicts with other modules must be resolved with importing mechanisms, but not by finding names that are different from all other identifiers in all other modules in all other packages. It just makes no sense to have a nice module system, but use it like the #include directive of the C preprocessor and eventually maybe complain about the deficiencies of the current module system. _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Anthony Cowley
Am 22.02.2014 20:51, schrieb Anthony Cowley:
> 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. Can you promise that you will use tight version bounds on 'base' if you import Data.Bits unqualified and without explicit import list in order to conform to the PVP? _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Henning Thielemann-4
On Mon, Feb 24, 2014 at 10:47:47AM +0100, Henning Thielemann wrote: > ... only if you plan to add another "zero" thing to the Data.Bits > module. Conflicts with other modules must be resolved with importing > mechanisms, but not by finding names that are different from all > other identifiers in all other modules in all other packages. It > just makes no sense to have a nice module system, but use it like > the #include directive of the C preprocessor and eventually maybe > complain about the deficiencies of the current module system. Yes, I'm thinking in the same way. Having "unique" names also seems to encourage to import modules unqualified, which sometimes is understandable - and I won't tell that I'm never doing it ;) - but at the end might have its own issues. Sure, the possibility to get future conflicts by importing 'zero' unqualified might be higher than with 'zeroBits', but using the qualified name 'Bits.zero' isn't any longer and it's more likely that you won't be getting conflicts in the future that way. And if you're having some local, algorithmic code, these post fixes like 'Bits' are just annoying and cluttering your code. Greetings, Daniel _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Edward Kmett-2
I agree with Edward that it would be better to reserve 'zero' for something like
an additive identity. I'll withdraw my +1 for the name `zero`, in favor of +1 for `zeroBits`. Twan On 22/02/14 16:48, Edward Kmett wrote: > I am notably strongly against taking 'zero' as it is much more appropriately > used by more algebraic classes, and it is an annoyingly common name to take for > such an often unqualified import. > > -Edward > > > On Sat, Feb 22, 2014 at 5:03 AM, Herbert Valerio Riedel <[hidden email] > <mailto:[hidden email]>> wrote: > > Hello *, > > Here's a mid-discussion summary 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>' > > from my point of view: > > - The idea came up already in 2011 when Num-superclass was to be removed > from Bits > (but discussion derailed) > > - So far general consensus (i.e. no "-1"s afaics) it's desired to have > an all-bits-clear value introducing method in 'Bits' > > - Use "clearBit (bit 0) 0" as default implementation for smooth upgrade-path > > - Nameing for <0-value-method> boils down to two candidates: > > a) 'Data.Bits.zero' > > - based on the idea tha 'Data.Bits' ought to be imported > qualified (or with explicit import-list) anyway > (-> thus following PVP practice) > > - many existing Data.Bits.Bits methods such as 'rotate', > 'complement', 'popCount', 'xor', or 'shift' don't have > the name 'bit' in it (and those few that have, operate > on single bits) > > - supporters (in no particular order): > > - ARJANEN Loïc Jean David > - Henning Thielemann > - Herbert Valerio Riedel (+0.99) > - Twan van Laarhoven > > b) 'Data.Bits.zeroBits' > > - more verbose name reduces risk of namespace conflicts with > unqualified imports > > - supporters (in no particular order): > > - Edward Kmett > - Eric Mertens > - Herbert Valerio Riedel > - Twan van Laarhoven > - (maybe?) ARJANEN Loïc Jean David > > > 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'. > > > Cheers, > hvr > _______________________________________________ > Libraries mailing list > [hidden email] <mailto:[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 |
Free forum by Nabble | Edit this page |