www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Get rid of bit and bit[] ?

reply "Walter Bright" <newshound digitalmars.com> writes:
I think the basic type bit has been a failure. It's a substantial increase 
in the compiler and runtime complexity to support it. Nobody seems happy 
about bit being a boolean type. There's no reasonable way to take a pointer 
to a bit, meaning that out and inout bit parameters are inconsistent and 
kludgy.

Should bit and bit[] be removed before 1.0?

There is a place for bit[] as a library type, though.

So what do people think? 
Feb 16 2006
next sibling parent reply John Stoneham <captnjameskirk moc.oohay> writes:
Walter Bright wrote:
 I think the basic type bit has been a failure. It's a substantial increase 
 in the compiler and runtime complexity to support it. Nobody seems happy 
 about bit being a boolean type. There's no reasonable way to take a pointer 
 to a bit, meaning that out and inout bit parameters are inconsistent and 
 kludgy.
 
 Should bit and bit[] be removed before 1.0?
 
 There is a place for bit[] as a library type, though.
 
 So what do people think? 
 
 

I think you shouldn't remove it unless you are replacing it with a true (pardon the pun) boolean type. To me, bool doesn't have to be a completely distinct type from, say, int (it could even be an alias for int). But it should still be an available type.
Feb 16 2006
parent reply Sean Kelly <sean f4.ca> writes:
John Stoneham wrote:
 Walter Bright wrote:
 I think the basic type bit has been a failure. It's a substantial 
 increase in the compiler and runtime complexity to support it. Nobody 
 seems happy about bit being a boolean type. There's no reasonable way 
 to take a pointer to a bit, meaning that out and inout bit parameters 
 are inconsistent and kludgy.

 Should bit and bit[] be removed before 1.0?

 There is a place for bit[] as a library type, though.

 So what do people think?

I think you shouldn't remove it unless you are replacing it with a true (pardon the pun) boolean type. To me, bool doesn't have to be a completely distinct type from, say, int (it could even be an alias for int). But it should still be an available type.

Good point. If 'bit' is going away then we need some form of boolean type to replace it. But I'll accept it being as loosely defined as bit is now--my primary concern is that its value must always be either 'true' or 'false'. Sean
Feb 16 2006
parent reply "Kris" <fu bar.com> writes:
Bit could be aliased in the interim.


"Sean Kelly" <sean f4.ca> wrote...
 John Stoneham wrote:
 Walter Bright wrote:
 I think the basic type bit has been a failure. It's a substantial 
 increase in the compiler and runtime complexity to support it. Nobody 
 seems happy about bit being a boolean type. There's no reasonable way to 
 take a pointer to a bit, meaning that out and inout bit parameters are 
 inconsistent and kludgy.

 Should bit and bit[] be removed before 1.0?

 There is a place for bit[] as a library type, though.

 So what do people think?

I think you shouldn't remove it unless you are replacing it with a true (pardon the pun) boolean type. To me, bool doesn't have to be a completely distinct type from, say, int (it could even be an alias for int). But it should still be an available type.

Good point. If 'bit' is going away then we need some form of boolean type to replace it. But I'll accept it being as loosely defined as bit is now--my primary concern is that its value must always be either 'true' or 'false'. Sean

Feb 16 2006
parent reply S. Chancellor <dnewsgr mephit.kicks-ass.org> writes:
On 2006-02-16 18:43:32 -0800, "Kris" <fu bar.com> said:

 Bit could be aliased in the interim.

Why can't it be an enumerated type? enum bool { true = 1, false = 0 } From the documentation: Named enum members can be implicitly cast to integral types, but integral types cannot be implicitly cast to an enum type. Seems like this is the functionality we're looking for? Or am I confused? -S.
Feb 16 2006
next sibling parent "Kris" <fu bar.com> writes:
"S. Chancellor" <dnewsgr mephit.kicks-ass.org> wrote
 On 2006-02-16 18:43:32 -0800, "Kris" <fu bar.com> said:

 Bit could be aliased in the interim.

Why can't it be an enumerated type? enum bool { true = 1, false = 0 } From the documentation: Named enum members can be implicitly cast to integral types, but integral types cannot be implicitly cast to an enum type. Seems like this is the functionality we're looking for? Or am I confused?

Yes, that's the gist of it ~ for those folks who currently use bit as a type (rather than bool), then bit could be aliased to whatever replaces it. Perhaps to the enum you illustrated above. This branch of the topic started, I think, with a concern from Thomas regarding the removal of bit[] whilst leaving bit. I think we were just trying to show how both can be removed without causing lots of grief for existing code.
Feb 16 2006
prev sibling next sibling parent reply =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
S. Chancellor wrote:
 Why can't it be an enumerated type?
 
 enum bool {
     true = 1,
     false = 0
 }

Because an integer can be converted to a enumerated type easily: enum Bool { True = 1, False = 0 } void main() { Bool b1 = Bool.False; Bool b2 = Bool.True; Bool b3 = cast(Bool)3; // No cast exception thrown. }
Feb 16 2006
next sibling parent reply S. Chancellor <dnewsgr mephit.kicks-ass.org> writes:
On 2006-02-16 20:28:20 -0800, Julio CÚsar Carrascal Urquijo   
<jcesar phreaker.net> said:

 Because an integer can be converted to a enumerated type easily:
 
 enum Bool
 {
      True = 1,
      False = 0
 }
 
 void main()
 {
 	Bool b1 = Bool.False;
 	Bool b2 = Bool.True;
 	Bool b3 = cast(Bool)3;	// No cast exception thrown.
 }

Well yeah, if you want to do that... Are you trying to write messed up code? -S.
Feb 16 2006
parent =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
S. Chancellor wrote:
 Well yeah, if you want to do that...  Are you trying to write messed up 
 code?

My point it's that the enum solution isn't any better than an alias to bit or a typedef to int which was the other proposed solution: typedef int bool; A bool type still needs to be implemented in the compiler to be a real Boolean type.
Feb 17 2006
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 16 Feb 2006 23:28:20 -0500, Julio CÚsar Carrascal Urquijo wrote:

 S. Chancellor wrote:
 Why can't it be an enumerated type?
 
 enum bool {
     true = 1,
     false = 0
 }

Because an integer can be converted to a enumerated type easily:

And you can do arithmetic with enums... enum Bool { True = 1, False = 0 } void main() { Bool b1 = Bool.False; Bool b2 = Bool.True; int b3 = b1 * 3 + (b2 - 7) / (b1 + Bool.True); } But you should not be able to do that with booleans. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocracy!" 17/02/2006 5:00:21 PM
Feb 16 2006
parent reply S. Chancellor <dnewsgr mephit.kicks-ass.org> writes:
On 2006-02-16 22:01:18 -0800, Derek Parnell <derek psych.ward> said:

 On Thu, 16 Feb 2006 23:28:20 -0500, Julio CÚsar Carrascal Urquijo wrote:
 
 S. Chancellor wrote:
 Why can't it be an enumerated type?
 
 enum bool {
 true = 1,
 false = 0
 }

Because an integer can be converted to a enumerated type easily:

And you can do arithmetic with enums... enum Bool { True = 1, False = 0 } void main() { Bool b1 = Bool.False; Bool b2 = Bool.True; int b3 = b1 * 3 + (b2 - 7) / (b1 + Bool.True); } But you should not be able to do that with booleans.

Says who? Why shouldn't you be able to do whatever you want with true and false provided you don't try to stuff them back into a bool?
Feb 17 2006
parent reply "Derek Parnell" <derek psych.ward> writes:
On Sat, 18 Feb 2006 02:07:58 +1100, S. Chancellor  
<dnewsgr mephit.kicks-ass.org> wrote:

 On 2006-02-16 22:01:18 -0800, Derek Parnell <derek psych.ward> said:

 On Thu, 16 Feb 2006 23:28:20 -0500, Julio C├ęsar Carrascal Urquijo wrote:

 S. Chancellor wrote:
 Why can't it be an enumerated type?
  enum bool {
 true = 1,
 false = 0
 }


enum Bool { True = 1, False = 0 } void main() { Bool b1 = Bool.False; Bool b2 = Bool.True; int b3 = b1 * 3 + (b2 - 7) / (b1 + Bool.True); } But you should not be able to do that with booleans.

Says who?

Obviously not *quite* everyone.
 Why shouldn't  you be able to do whatever you want with true and false  
 provided you don't try to stuff them back into a bool?

Because they do not belong in the domain of numbers. Because 'what is the square root of truth' is meaningless. Because we don't allow '"cat" + "harry" / ( "bob" - "stupid")'. Because 'false' is not zero, and 'true' is not one. Because zero is not 'false' and one is not 'true'. -- Derek Parnell Melbourne, Australia
Feb 17 2006
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:op.s44h81h56b8z09 ginger.vic.bigpond.net.au...
 Because they do not belong in the domain of numbers.
 Because 'what is the square root of truth' is meaningless.
 Because we don't allow '"cat" + "harry" / ( "bob" - "stupid")'.
 Because 'false' is not zero, and 'true' is not one.
 Because zero is not 'false' and one is not 'true'.

I agree with everything but the last two lines. If there's anything that irritates me, it's when a language makes it very difficult to convert between ints and bools. While I will accept the fact that bools abstract the ideas of "true" and "false," I think it's still useful to allow them to be represented by their true, numerical representation.
Feb 17 2006
parent reply "Derek Parnell" <derek psych.ward> writes:
On Sat, 18 Feb 2006 07:44:13 +1100, Jarrett Billingsley  
<kb3ctd2 yahoo.com> wrote:

 "Derek Parnell" <derek psych.ward> wrote in message
 news:op.s44h81h56b8z09 ginger.vic.bigpond.net.au...
 Because they do not belong in the domain of numbers.
 Because 'what is the square root of truth' is meaningless.
 Because we don't allow '"cat" + "harry" / ( "bob" - "stupid")'.
 Because 'false' is not zero, and 'true' is not one.
 Because zero is not 'false' and one is not 'true'.

I agree with everything but the last two lines. If there's anything that irritates me, it's when a language makes it very difficult to convert between ints and bools. While I will accept the fact that bools abstract the ideas of "true" and "false," I think it's still useful to allow them to be represented by their true, numerical representation.

'Truth' is not a number so why do you insist that 'true' is 1? 'Falsehood' is not a number so why do you insist that 'false' is 0? The numbers 1 and 0 are used as one of the miriad of possible representations of truth and falsehood. There is nothing intrinsic about these numbers but they are practical. For example, some programming languages use -1 to *represent* truth. I too would be irritated if I couldn't code the shorthand ... while( <numeric_expression> ) ... but it is just that, *shorthand*, for ... while( <numeric_expression> != 0 ) ... which evaluates to a boolean result. The <numeric_expression> itself is not truth or falsehood, but the equality test for that expression is. -- Derek Parnell Melbourne, Australia
Feb 17 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:op.s440fct36b8z09 ginger.vic.bigpond.net.au...
 'Truth' is not a number so why do you insist that 'true' is 1?
 'Falsehood' is not a number so why do you insist that 'false' is 0?

 The numbers 1 and 0 are used as one of the miriad of possible 
 representations of truth and falsehood. There is nothing intrinsic about 
 these numbers but they are practical. For example, some programming 
 languages use -1 to *represent* truth.

The only argument I have against that is that to a computer, 1 means true and 0 means false. And we're dealing with a computer here. It has become such a standard that 1 represents true and 0 represents false that those languages which do use other representations (such as -1 in.. VB IIRC) end up being something of a pain to interface with from the myriad of other languages which use 1 for true and 0 for false. What does this extra, minor layer of abstraction really gain you, anyway?
Feb 17 2006
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Jarrett Billingsley wrote:
 The only argument I have against that is that to a computer, 1 means true 
 and 0 means false.  And we're dealing with a computer here.  It has become 
 such a standard that 1 represents true and 0 represents false that those 
 languages which do use other representations (such as -1 in.. VB IIRC) end 
 up being something of a pain to interface with from the myriad of other 
 languages which use 1 for true and 0 for false.  What does this extra, minor 
 layer of abstraction really gain you, anyway? 
 

Computers don't have inteligence nor understanding of our concepts so true and false mean nothing to them. Also: we are talking about a programming language that is meant to be writen by humans so we are actually talking about humans that have a concept of true and false and Boolean algebra. The actual representation of true and false from this point of view has no meaning. I will also add here that i agree with most of what Derek said in his bool-related posts except: if(17) <- this means nothing to me? is 17 true or false? Although I know it is very unlikely to happen I would be happiest if 'if' and 'while' excepted *only* boolean arguments. Maybe I know what 'if(number)' means but 'if(number != 0)' is much more understandable and maintainable.
Feb 17 2006
parent reply "Derek Parnell" <derek psych.ward> writes:
On Sat, 18 Feb 2006 11:07:03 +1100, Ivan Senji  
<ivan.senji_REMOVE_ _THIS__gmail.com> wrote:

 if(17) <- this means nothing to me? is 17 true or false?

 Although I know it is very unlikely to happen I would be happiest if  
 'if' and 'while' excepted *only* boolean arguments.

 Maybe I know what 'if(number)' means but 'if(number != 0)' is much more  
 understandable and maintainable.

I tend to agree with the readibility aspect here and I also tend to write code like this out in full too. But there are other people who do not and it isn't that hard to mentally translate the intention, so I'll not complain too much about its continued existance. -- Derek Parnell Melbourne, Australia
Feb 17 2006
parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Derek Parnell wrote:
 On Sat, 18 Feb 2006 11:07:03 +1100, Ivan Senji  
 <ivan.senji_REMOVE_ _THIS__gmail.com> wrote:
 
 if(17) <- this means nothing to me? is 17 true or false?

 Although I know it is very unlikely to happen I would be happiest if  
 'if' and 'while' excepted *only* boolean arguments.

 Maybe I know what 'if(number)' means but 'if(number != 0)' is much 
 more  understandable and maintainable.

I tend to agree with the readibility aspect here and I also tend to write code like this out in full too. But there are other people who do not and it isn't that hard to mentally translate the intention, so I'll not complain too much about its continued existance.

Nor will I (too much time spent in this NG :)
Feb 18 2006
prev sibling next sibling parent "Kris" <fu bar.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote ...
 "Derek Parnell" <derek psych.ward> wrote in message 
 news:op.s440fct36b8z09 ginger.vic.bigpond.net.au...
 'Truth' is not a number so why do you insist that 'true' is 1?
 'Falsehood' is not a number so why do you insist that 'false' is 0?

 The numbers 1 and 0 are used as one of the miriad of possible 
 representations of truth and falsehood. There is nothing intrinsic about 
 these numbers but they are practical. For example, some programming 
 languages use -1 to *represent* truth.

The only argument I have against that is that to a computer, 1 means true and 0 means false. And we're dealing with a computer here. It has become such a standard that 1 represents true and 0 represents false that those languages which do use other representations (such as -1 in.. VB IIRC) end up being something of a pain to interface with from the myriad of other languages which use 1 for true and 0 for false. What does this extra, minor layer of abstraction really gain you, anyway?

If you look at CPU designs, you'll very often see a CPU-flag for zero/non-zero. Controlling that flag is typically supported by a few short 'test' instructions, whereas testing against 1 or some other value may involve an additional instruction (there are some notable exceptions, such as the H8 family). Thus it's not unusual to see false defined as 0, and true defined as !false, or ~false. However, it's rather likely that D will assume the same values for true and false as DMC; whatever those are.
Feb 17 2006
prev sibling parent "Derek Parnell" <derek psych.ward> writes:
On Sat, 18 Feb 2006 10:45:34 +1100, Jarrett Billingsley  
<kb3ctd2 yahoo.com> wrote:

 "Derek Parnell" <derek psych.ward> wrote in message
 news:op.s440fct36b8z09 ginger.vic.bigpond.net.au...
 'Truth' is not a number so why do you insist that 'true' is 1?
 'Falsehood' is not a number so why do you insist that 'false' is 0?

 The numbers 1 and 0 are used as one of the miriad of possible
 representations of truth and falsehood. There is nothing intrinsic about
 these numbers but they are practical. For example, some programming
 languages use -1 to *represent* truth.

The only argument I have against that is that to a computer, 1 means true and 0 means false. And we're dealing with a computer here. It has become such a standard that 1 represents true and 0 represents false that those languages which do use other representations (such as -1 in.. VB IIRC) end up being something of a pain to interface with from the myriad of other languages which use 1 for true and 0 for false.

I believe that we are actually dealing with a computer *programming language* and not a computer. It is the compiler that is dealing with the computer, not us. The compiler is free to assign 1 to truth and 0 to falsehood if its worthwhile. But a programming language is for people to use to express algortihms in a manner that is easier to do than other methods and to help us communicate that algorithm to other *people*. It is the compiler that does the hard work of converting that human-friendly expression into hardware-friendly code.
 What does this extra, minor layer of abstraction really gain you, anyway?

It encourages humans to think about the problem rather than the mechanics of the problem's implementation in machine code. -- Derek Parnell Melbourne, Australia
Feb 17 2006
prev sibling parent reply John Stoneham <captnjameskirk moc.oohay> writes:
 Because they do not belong in the domain of numbers.
 Because 'what is the square root of truth' is meaningless.
 Because we don't allow '"cat" + "harry" / ( "bob" - "stupid")'.
 Because 'false' is not zero, and 'true' is not one.
 Because zero is not 'false' and one is not 'true'.
 

This is one thing I really like about Ada. The compiler will just not let you do ANYTHING with a type that requires any kind of implied cast. Boolean is Boolean and nothing else. If you've got a Boolean variable, you can't add an integer to it, you can't assigned anything other than another Boolean to it, and you can't use anything other than a Boolean in it's place. You can't do something like "while(x)" unless x was declared a Boolean type. This extreme type safety in Ada takes a little getting used to, especially if you do a lot of "while(1)"-style shortcuts, but it really becomes your friend and saves you from a lot of unintentional bugs later (not that there's ever an *intentional* bug, but you know what I mean).
Feb 18 2006
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
John Stoneham wrote:
 Because they do not belong in the domain of numbers.
 Because 'what is the square root of truth' is meaningless.
 Because we don't allow '"cat" + "harry" / ( "bob" - "stupid")'.
 Because 'false' is not zero, and 'true' is not one.
 Because zero is not 'false' and one is not 'true'.

This is one thing I really like about Ada. The compiler will just not let you do ANYTHING with a type that requires any kind of implied cast. Boolean is Boolean and nothing else. If you've got a Boolean variable, you can't add an integer to it, you can't assigned anything other than another Boolean to it, and you can't use anything other than a Boolean in it's place. You can't do something like "while(x)" unless x was declared a Boolean type. This extreme type safety in Ada takes a little getting used to, especially if you do a lot of "while(1)"-style shortcuts, but it really becomes your friend and saves you from a lot of unintentional bugs later (not that there's ever an *intentional* bug, but you know what I mean).

I think every language that claims to be type-safe should behave that way. Boolean is boolean and nothing else, and the way that it is implemented (byte, int, float, 0==true, 0==false) is of no importance.
Feb 18 2006
parent John Stoneham <captnjameskirk moc.oohay> writes:
Ivan Senji wrote:
 I think every language that claims to be type-safe should behave that 
 way. Boolean is boolean and nothing else, and the way that it is 
 implemented (byte, int, float, 0==true, 0==false) is of no importance.

Agreed. I would not like this to be allowed without a compiler error: int x = 1; bool B = x; This should be required: bool B = cast(bool)x; Along the same lines, this currently bugs the hell out me as not raising a compile-time error: long long_x = 4294967296; // int overflow int some_int = long_x; The value of some_int is now 0, definitely not a desired result. What if bool is implemented as an int, but "cast" is not required in an assignment? The value of long_x above is positive, so that should be evaluate to true after B = long_x, right? Well, not if bool is implemented as an int. Then it would be *false* because converting the long value of 4294967296 to an int results in a value of 0. This can (and should, IMO) raise an error at compile time.
Feb 18 2006
prev sibling next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"John Stoneham" <captnjameskirk moc.oohay> wrote in message 
news:dt6rqj$1rk1$1 digitaldaemon.com...
 This is one thing I really like about Ada. The compiler will just not let 
 you do ANYTHING with a type that requires any kind of implied cast.

I have no experience with Ada, but Pascal requires this too. After programming in it for a while, it just became really annoying to not have at least some implicit conversions. One significant problem with requiring casting all over the place is that casting is a crude cudgel, and can actually reduce typesafety because it'll attempt to bash anything into anything else.
Feb 18 2006
parent reply John Stoneham <captnjameskirk moc.oohay> writes:
Walter Bright wrote:
 "John Stoneham" <captnjameskirk moc.oohay> wrote in message 
 news:dt6rqj$1rk1$1 digitaldaemon.com...
 This is one thing I really like about Ada. The compiler will just not let 
 you do ANYTHING with a type that requires any kind of implied cast.

I have no experience with Ada, but Pascal requires this too. After programming in it for a while, it just became really annoying to not have at least some implicit conversions. One significant problem with requiring casting all over the place is that casting is a crude cudgel, and can actually reduce typesafety because it'll attempt to bash anything into anything else.

Well, with Ada the solution is to allow a wide range of user-defined types and subtypes. I rarely find it necessary to cast, despite the fact that Ada is *extremely* type-safe (in fact, type safety was the main point of the language design). If you've got a type-safe language, you design your program around and with it. For example, you can define your own type of Integer that has a range of 2 .. 11, and attempting to assign a value of 12 to a variable of your type raises an error. There is no implicit cast, even though they may both integer-based. If you attempt to assign a variable of type Integer to a variable of your new type, you get a compile error, and vise-versa. If you explicitly cast the Integer variable to your new type, you will get a runtime error is the value is outside your defined range, or a compile error if the compiler can deduce the value at compile-time. Subtypes are a little different and allow some implicit casts. It is possible to use a subtype anywhere the type from which it is derived is used (since the subtype is by definition within the range of the base type). But trying it the other way around *does* raise an error. I know that sounds like a complicated description (and it's not complete by any means). And at first glance it sounds limiting in what you can do. But it's really very flexible, and I can't tell you how many bugs it saved me from.
Feb 18 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"John Stoneham" <captnjameskirk moc.oohay> wrote in message 
news:dt7rj2$2lgj$1 digitaldaemon.com...
 I know that sounds like a complicated description (and it's not complete 
 by any means). And at first glance it sounds limiting in what you can do. 
 But it's really very flexible, and I can't tell you how many bugs it saved 
 me from.

I believe you. My main concern, though, is that Ada has failed to gain traction in the general programming community. I don't know why this is so, but it makes me very cautious about adopting Ada style.
Feb 18 2006
parent John Stoneham <captnjameskirk moc.oohay> writes:
Walter Bright wrote:
 "John Stoneham" <captnjameskirk moc.oohay> wrote in message 
 news:dt7rj2$2lgj$1 digitaldaemon.com...
 I know that sounds like a complicated description (and it's not complete 
 by any means). And at first glance it sounds limiting in what you can do. 
 But it's really very flexible, and I can't tell you how many bugs it saved 
 me from.

I believe you. My main concern, though, is that Ada has failed to gain traction in the general programming community. I don't know why this is so, but it makes me very cautious about adopting Ada style.

Oh I can tell you precisely why it hasn't gained traction in the general programming community (or at least why I personally couldn't stay with it for more than the 5 years I've given it), and there are 2 reasons: 1) For an individual user, the language specification is just *enormous*, and this complaint has nothing to do with the type system (which is my favorite thing about Ada), it has to do with making the "standard library" part of the actual language specification instead of just a library of useful functions which you can use when you need them. It shares this same problem with Common Lisp. 2) The package system is too damn finicky. If you're just wanting to put a utility function in a separate file to be reused later, there are too many little things you have to set up just right to get it to work. As long as D can avoid these 2 things, I think it will eventually gain a large following.
Feb 18 2006
prev sibling parent Niko Korhonen <niktheblak hotmail.com> writes:
John Stoneham wrote:
 This is one thing I really like about Ada. The compiler will just not 
 let you do ANYTHING with a type that requires any kind of implied cast. 
 Boolean is Boolean and nothing else. If you've got a Boolean variable, 
 you can't add an integer to it, you can't assigned anything other than 
 another Boolean to it, and you can't use anything other than a Boolean 
 in it's place.

That's indeed how a type safe language should behave. Fine examples are statically typed functional languages Haskell and O'Caml, which are *absolutely* type-safe. That is, they have very clear and strict type rules with no casts. In Haskell converting a truth value to integer is done via the obvious approach: b = true i = if b then 1 else 0 Also you can just forget about accidentally mixing signed and unsigned values :) This hasn't really bothered me at all while programming in Haskell or O'Caml. I would gladly exchange "easy boolean to integer conversion" you people seem to appreciate so much for type safety. -- Niko Korhonen SW Developer
Feb 22 2006
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 16 Feb 2006 20:05:58 -0800, S. Chancellor wrote:

 On 2006-02-16 18:43:32 -0800, "Kris" <fu bar.com> said:
 
 Bit could be aliased in the interim.

Why can't it be an enumerated type? enum bool { true = 1, false = 0 } From the documentation: Named enum members can be implicitly cast to integral types, but integral types cannot be implicitly cast to an enum type. Seems like this is the functionality we're looking for? Or am I confused?

Yes <g>. This is only a small partial solution and one that brings other problems as well. Try it out to see what I mean. In essence though, its still an integer and not a boolean. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocracy!" 17/02/2006 4:54:16 PM
Feb 16 2006
parent Georg Wrede <georg.wrede nospam.org> writes:
Derek Parnell wrote:
 On Thu, 16 Feb 2006 20:05:58 -0800, S. Chancellor wrote:
 On 2006-02-16 18:43:32 -0800, "Kris" <fu bar.com> said:
 
 Bit could be aliased in the interim.

Why can't it be an enumerated type? enum bool { true = 1, false = 0 } From the documentation: Named enum members can be implicitly cast to integral types, but integral types cannot be implicitly cast to an enum type. Seems like this is the functionality we're looking for? Or am I confused?

Yes <g>. This is only a small partial solution and one that brings other problems as well. Try it out to see what I mean. In essence though, its still an integer and not a boolean.

Anybody ever thought of _why_ we have both & and && ? Thinking that through will make most of this entire thread redundant.
Feb 17 2006
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 16 Feb 2006 16:47:21 -0800, Walter Bright wrote:

 I think the basic type bit has been a failure. It's a substantial increase 
 in the compiler and runtime complexity to support it. Nobody seems happy 
 about bit being a boolean type. There's no reasonable way to take a pointer 
 to a bit, meaning that out and inout bit parameters are inconsistent and 
 kludgy.
 
 Should bit and bit[] be removed before 1.0?
 
 There is a place for bit[] as a library type, though.
 
 So what do people think?

I regard a 'bit' as a part of a collection. Access to groups of one or more adjacent bits seems to be a normal system programming function and should not be hampered. What would be useful is to make easy syntax to access them rather than combinations of '&', '~', and '|'. So maybe the idea like bit structures that allow us to name bit collections and have D do the fancy stuff for us. A collection of bits could be regarded as tiny unsigned integers. A boolean exhibits the follow characteristics: ** It has only ever two states. Let's call then true and false for now. ** It can not take part in arithmetic. The compiler must flag this as an error. ** It can not take part in relative comparisons (ie. > < >= <=). The compiler must flag this as an error. ** It can take part in equality tests (==, !=) ** The ! operand returns the value which it is currently not. ** The binary operands ( ~ & | ) are not permitted. ** The boolean operands ( ! && || ) are permitted ** It can be explicitly cast to an integer such that false is 0, and true is 1. ** A numeric value can be explicitly cast to a boolean such that 0 is false, and non-zero is true. ** It's formatted %s value is either "false" or "true" ** It's formatted %d value is either 0 or 1 ** How this is implemented is not relevant from the coders POV, so if you use an int or short or byte to represent a boolean's storage that's just fine. ** boolean.size should return the number of bytes used to implement it. ** boolean.init should be false ** boolean.min should not be allowed ** boolean.max should not be allowed ** An array of booleans is permitted. ** Address of a boolean is permitted. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocracy!" 17/02/2006 12:03:48 PM
Feb 16 2006
next sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Derek Parnell wrote:
 On Thu, 16 Feb 2006 16:47:21 -0800, Walter Bright wrote:
 
 
I think the basic type bit has been a failure. It's a substantial increase 
in the compiler and runtime complexity to support it. Nobody seems happy 
about bit being a boolean type. There's no reasonable way to take a pointer 
to a bit, meaning that out and inout bit parameters are inconsistent and 
kludgy.

Should bit and bit[] be removed before 1.0?

There is a place for bit[] as a library type, though.

So what do people think?


 
 A boolean exhibits the follow characteristics:
 ** It has only ever two states. Let's call then true and false for now.
 ** It can not take part in arithmetic. The compiler must flag this as an
 error.
 ** It can not take part in relative comparisons (ie. > < >= <=).  The
 compiler must flag this as an error.
 ** It can take part in equality tests (==, !=)
 ** The ! operand returns the value which it is currently not.
 ** The binary operands ( ~ &  | ) are not permitted.
 ** The boolean operands ( ! && || ) are permitted
 ** It can be explicitly cast to an integer such that false is 0, and true
 is 1.
 ** A numeric value can be explicitly cast to a boolean such that 0 is
 false, and non-zero is true.
 ** It's formatted %s value is either "false" or "true" 
 ** It's formatted %d value is either 0 or 1
 ** How this is implemented is not relevant from the coders POV, so if you
 use an int or short or byte to represent a boolean's storage that's just
 fine.
 ** boolean.size should return the number of bytes used to implement it.
 ** boolean.init should be false
 ** boolean.min should not be allowed
 ** boolean.max should not be allowed
 ** An array of booleans is permitted.
 ** Address of a boolean is permitted.
 

Well said! This is what bools should before 1.0!
Feb 16 2006
prev sibling next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Derek Parnell wrote:
 On Thu, 16 Feb 2006 16:47:21 -0800, Walter Bright wrote:
 
 I think the basic type bit has been a failure. It's a substantial increase 
 in the compiler and runtime complexity to support it. Nobody seems happy 
 about bit being a boolean type. There's no reasonable way to take a pointer 
 to a bit, meaning that out and inout bit parameters are inconsistent and 
 kludgy.

 Should bit and bit[] be removed before 1.0?

 There is a place for bit[] as a library type, though.

 So what do people think?

I regard a 'bit' as a part of a collection. Access to groups of one or more adjacent bits seems to be a normal system programming function and should not be hampered. What would be useful is to make easy syntax to access them rather than combinations of '&', '~', and '|'. So maybe the idea like bit structures that allow us to name bit collections and have D do the fancy stuff for us. A collection of bits could be regarded as tiny unsigned integers. A boolean exhibits the follow characteristics: ** It has only ever two states. Let's call then true and false for now. ** It can not take part in arithmetic. The compiler must flag this as an error. ** It can not take part in relative comparisons (ie. > < >= <=). The compiler must flag this as an error. ** It can take part in equality tests (==, !=) ** The ! operand returns the value which it is currently not. ** The binary operands ( ~ & | ) are not permitted. ** The boolean operands ( ! && || ) are permitted ** It can be explicitly cast to an integer such that false is 0, and true is 1. ** A numeric value can be explicitly cast to a boolean such that 0 is false, and non-zero is true. ** It's formatted %s value is either "false" or "true" ** It's formatted %d value is either 0 or 1 ** How this is implemented is not relevant from the coders POV, so if you use an int or short or byte to represent a boolean's storage that's just fine. ** boolean.size should return the number of bytes used to implement it. ** boolean.init should be false ** boolean.min should not be allowed ** boolean.max should not be allowed ** An array of booleans is permitted. ** Address of a boolean is permitted.

Hear Hear!
Feb 16 2006
prev sibling next sibling parent reply Tom <Tom_member pathlink.com> writes:
In article <14shfnb64x5o2.17cec6fac7wnu.dlg 40tude.net>, Derek Parnell says...
On Thu, 16 Feb 2006 16:47:21 -0800, Walter Bright wrote:

 I think the basic type bit has been a failure. It's a substantial increase 
 in the compiler and runtime complexity to support it. Nobody seems happy 
 about bit being a boolean type. There's no reasonable way to take a pointer 
 to a bit, meaning that out and inout bit parameters are inconsistent and 
 kludgy.
 
 Should bit and bit[] be removed before 1.0?
 
 There is a place for bit[] as a library type, though.
 
 So what do people think?

I regard a 'bit' as a part of a collection. Access to groups of one or more adjacent bits seems to be a normal system programming function and should not be hampered. What would be useful is to make easy syntax to access them rather than combinations of '&', '~', and '|'. So maybe the idea like bit structures that allow us to name bit collections and have D do the fancy stuff for us. A collection of bits could be regarded as tiny unsigned integers. A boolean exhibits the follow characteristics: ** It has only ever two states. Let's call then true and false for now. ** It can not take part in arithmetic. The compiler must flag this as an error. ** It can not take part in relative comparisons (ie. > < >= <=). The compiler must flag this as an error. ** It can take part in equality tests (==, !=) ** The ! operand returns the value which it is currently not. ** The binary operands ( ~ & | ) are not permitted. ** The boolean operands ( ! && || ) are permitted ** It can be explicitly cast to an integer such that false is 0, and true is 1. ** A numeric value can be explicitly cast to a boolean such that 0 is false, and non-zero is true. ** It's formatted %s value is either "false" or "true" ** It's formatted %d value is either 0 or 1 ** How this is implemented is not relevant from the coders POV, so if you use an int or short or byte to represent a boolean's storage that's just fine. ** boolean.size should return the number of bytes used to implement it. ** boolean.init should be false ** boolean.min should not be allowed ** boolean.max should not be allowed ** An array of booleans is permitted. ** Address of a boolean is permitted.

Perfectly defined! A quote in spanish: "Mßs claro, echarle agua". In english it'd be something like "To get it clearer, pour water on it". Amen. You have my vote to remove 'bit' and replace it with 'bool'. P.S.: Lately I've been having the feeling that D is getting TOO overloaded. The last threads made me feel a little dizzy. Maybe it's time to add only the most relevant lacking features (and remove/replace the most unwanted, unpopular and irrelevant ones) and complete/improve the infrastructure to make D a true competitor. Tom;
Feb 16 2006
parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
[snip]
 P.S.: Lately I've been having the feeling that D is getting TOO overloaded. The
 last threads made me feel a little dizzy. Maybe it's time to add only the most
 relevant lacking features (and remove/replace the most unwanted, unpopular and
 irrelevant ones) and complete/improve the infrastructure to make D a true
 competitor. 
 
 Tom;

I'm getting this feeling too .. The main overview page http://digitalmars.com/d/overview.html says:
C++ programmers tend to program in particular islands of the language,
i.e. getting very proficient using certain features while avoiding
other feature sets. While the code is usually portable from compiler to
compiler, it can be hard to port it from programmer to programmer. A
great strength of C++ is that it can support many radically different
styles of programming - but in long term use, the overlapping and
contradictory styles are a hindrance.

This is true for D too, now.
Feb 16 2006
prev sibling parent Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Derek Parnell wrote:
 A boolean exhibits the follow characteristics:
 ** It has only ever two states. Let's call then true and false for now.
 ** It can not take part in arithmetic. The compiler must flag this as an
 error.
 ** It can not take part in relative comparisons (ie. > < >= <=).  The
 compiler must flag this as an error.
 ** It can take part in equality tests (==, !=)
 ** The ! operand returns the value which it is currently not.
 ** The binary operands ( ~ &  | ) are not permitted.
 ** The boolean operands ( ! && || ) are permitted
 ** It can be explicitly cast to an integer such that false is 0, and true
 is 1.
 ** A numeric value can be explicitly cast to a boolean such that 0 is
 false, and non-zero is true.
 ** It's formatted %s value is either "false" or "true" 
 ** It's formatted %d value is either 0 or 1
 ** How this is implemented is not relevant from the coders POV, so if you
 use an int or short or byte to represent a boolean's storage that's just
 fine.
 ** boolean.size should return the number of bytes used to implement it.
 ** boolean.init should be false
 ** boolean.min should not be allowed
 ** boolean.max should not be allowed
 ** An array of booleans is permitted.
 ** Address of a boolean is permitted.
 

As long as we get a boolean along these lines - of size 1 bit, 8 bits, 32 bits, 64 bits, whatever -, I don't really care what happens to bit/bit[]. I haven't yet used bit[] at all, except in a few cases where I thought I could use it as a "normal" array of booleans. Of course, that doesn't count, since the code didn't behave as I expected.
Feb 17 2006
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 I think the basic type bit has been a failure. It's a substantial increase 
 in the compiler and runtime complexity to support it. Nobody seems happy 
 about bit being a boolean type. There's no reasonable way to take a pointer 
 to a bit, meaning that out and inout bit parameters are inconsistent and 
 kludgy.
 
 Should bit and bit[] be removed before 1.0?
 
 There is a place for bit[] as a library type, though.
 
 So what do people think?

Please remove it. Packed bit arrays are a good thing, but not as a language feature in this case. Sean
Feb 16 2006
prev sibling next sibling parent "Kris" <fu bar.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote ..
I think the basic type bit has been a failure. It's a substantial increase 
in the compiler and runtime complexity to support it. Nobody seems happy 
about bit being a boolean type. There's no reasonable way to take a pointer 
to a bit, meaning that out and inout bit parameters are inconsistent and 
kludgy.

 Should bit and bit[] be removed before 1.0?

 There is a place for bit[] as a library type, though.

 So what do people think?

Yes; please do. A library class or struct BitSet, perhaps with some jolly op-overloads (such as opIndex and friends), would do the job very nicely instead.
Feb 16 2006
prev sibling next sibling parent AgentOrange <AgentOrange_member pathlink.com> writes:
In article <dt36tu$1lg3$2 digitaldaemon.com>, Walter Bright says...
I think the basic type bit has been a failure. It's a substantial increase 
in the compiler and runtime complexity to support it. Nobody seems happy 
about bit being a boolean type. There's no reasonable way to take a pointer 
to a bit, meaning that out and inout bit parameters are inconsistent and 
kludgy.

Should bit and bit[] be removed before 1.0?

There is a place for bit[] as a library type, though.

So what do people think? 

I think a distinct boolean type of some kind should be availaible. In c++ I am always having to add a special boolean version of overridden methods, for example: void set( short val ); void set( int val ); void set( long val ); -> void setBool( bool val ); <- set( bool ) would conflict with set( int ) which then adds compounded complexity with templates(macros) etc.... so personally i think bool should at least be a built in typedef
Feb 16 2006
prev sibling next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 16 Feb 2006 16:47:21 -0800, Walter Bright  
<newshound digitalmars.com> wrote:

 I think the basic type bit has been a failure. It's a substantial  
 increase
 in the compiler and runtime complexity to support it. Nobody seems happy
 about bit being a boolean type. There's no reasonable way to take a  
 pointer
 to a bit, meaning that out and inout bit parameters are inconsistent and
 kludgy.

 Should bit and bit[] be removed before 1.0?

 There is a place for bit[] as a library type, though.

 So what do people think?

Yes, get rid of it. I think we need a "bool" type that can only have 2 values: true and false. I think we need some way to handle packed bits, a BitSet class/struct and/or a BitStream/BitBuffer class and library functions to hide the & | and ^ ickiness (there are some in std.intrinsic). Regan
Feb 16 2006
parent "Regan Heath" <regan netwin.co.nz> writes:
On Fri, 17 Feb 2006 16:05:52 +1300, Regan Heath <regan netwin.co.nz> wrote:
 On Thu, 16 Feb 2006 16:47:21 -0800, Walter Bright  
 <newshound digitalmars.com> wrote:

 I think the basic type bit has been a failure. It's a substantial  
 increase
 in the compiler and runtime complexity to support it. Nobody seems happy
 about bit being a boolean type. There's no reasonable way to take a  
 pointer
 to a bit, meaning that out and inout bit parameters are inconsistent and
 kludgy.

 Should bit and bit[] be removed before 1.0?

 There is a place for bit[] as a library type, though.

 So what do people think?

Yes, get rid of it. I think we need a "bool" type that can only have 2 values: true and false.

This type can be implemented however appropriate, for example it has been suggested that an int sized variable performs the best. Regardless, as long as the type can only have 2 values it will do the job I reckon. Regan
Feb 16 2006
prev sibling next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:
 I think the basic type bit has been a failure. It's a substantial
 increase in the compiler and runtime complexity to support it. Nobody
 seems happy about bit being a boolean type. There's no reasonable way
 to take a pointer to a bit, meaning that out and inout bit parameters
 are inconsistent and kludgy.
 
 Should bit and bit[] be removed before 1.0?
 
 There is a place for bit[] as a library type, though.
 
 So what do people think?

Yes, please remove!
Feb 16 2006
prev sibling next sibling parent One Wise Monkee <One_member pathlink.com> writes:
In article <dt36tu$1lg3$2 digitaldaemon.com>, Walter Bright says...
I think the basic type bit has been a failure. It's a substantial increase 
in the compiler and runtime complexity to support it. Nobody seems happy 
about bit being a boolean type. There's no reasonable way to take a pointer 
to a bit, meaning that out and inout bit parameters are inconsistent and 
kludgy.

Should bit and bit[] be removed before 1.0?

Stone dead.
There is a place for bit[] as a library type, though.

So what do people think? 

Firing squad immediately. No mercy
Feb 16 2006
prev sibling next sibling parent reply One Wise Monkee <One_member pathlink.com> writes:
I think the basic type bit has been a failure. It's a substantial increase 
in the compiler and runtime complexity to support it. Nobody seems happy 
about bit being a boolean type. There's no reasonable way to take a pointer 
to a bit, meaning that out and inout bit parameters are inconsistent and 
kludgy.

Maybe there is intent to Matthews' rsants and raves? Hes had some strong attacks on Walter in last month, and now like manna from heavan 3-4 long, long bugbears in D are being handled in some way or considered by The Man: bit, warnings, recls, $ & regexp. Is he golden prince still with the kings ear? Even if he is now exiled black prince he seems to serve e useful putpose. Shout again, naughty boy!
Feb 16 2006
next sibling parent "Kris" <fu bar.com> writes:
You're not fooling anyone, Matthew.


"One Wise Monkee" <One_member pathlink.com> wrote in message 
news:dt3h6b$1t7e$1 digitaldaemon.com...
I think the basic type bit has been a failure. It's a substantial 
increase
in the compiler and runtime complexity to support it. Nobody seems happy
about bit being a boolean type. There's no reasonable way to take a 
pointer
to a bit, meaning that out and inout bit parameters are inconsistent and
kludgy.

Maybe there is intent to Matthews' rsants and raves? Hes had some strong attacks on Walter in last month, and now like manna from heavan 3-4 long, long bugbears in D are being handled in some way or considered by The Man: bit, warnings, recls, $ & regexp. Is he golden prince still with the kings ear? Even if he is now exiled black prince he seems to serve e useful putpose. Shout again, naughty boy!

Feb 16 2006
prev sibling parent reply "Matthew" <matthew hat.stlsoft.dot.org> writes:
 Maybe there is intent to Matthews' rsants and raves? Hes had some strong

 on Walter in last month, and now like manna from heavan 3-4 long, long

 in D are being handled in some way or considered by The Man: bit,

 recls, $ & regexp.

A _highly_ doubtful proposition. I think Walter makes up his mind pretty much on technical merits alone. I suspect he's just reaching a level of momentum with the language as he perceives it and is simply clearing up (popular) outstanding issues. (btw, I'd hardly look upon the situation with recls any kind of victory, for anyone. But if you mean it's good to have _some_ resolution then I agree with that.) Good to hear bit's going though. I strongly support that, and the introduction of a bool(ean) replacement that is not implicitly convertible to an integral type. (But I'm not getting involved in a fracas on that point ... <g>) Matthew
Feb 16 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Matthew" <matthew hat.stlsoft.dot.org> wrote in message 
news:dt3utv$27h2$1 digitaldaemon.com...
 A _highly_ doubtful proposition.  I think Walter makes up his mind pretty
 much
 on technical merits alone. I suspect he's just reaching a level of 
 momentum
 with the
 language as he perceives it and is simply clearing up (popular) 
 outstanding
 issues.

I attended the NWCUG meeting yesterday, and got into a long discussion about D (NWCUG gets some top people to attend, so I can get some pretty good feedback). The discussion turned towards mistaken language ideas and any screwups in D, and of course I thought of bit. The others suggested why not remove bit? I had thought we were stuck with it for backwards compatibility reasons, but then I thought I'd pose the question here. There's also the issue brought up here that perhaps D is accreting too many kludgy features. Bit is certainly a kludgy feature with too many special cases, and so things would definitely get simpler without it. I definitely get the feeling that D is gaining momentum. Everywhere I go now, people have heard of D. They may not be writing programs in it yet, but they're aware of it and a lot of influential people are keeping tabs on its progress. I've been invited to give yet another presentation on D at a major company tomorrow.
Feb 17 2006
parent Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:

 The others suggested why not remove bit?

Aw, crap! And I thought our unanimous opinion had something to do with it! ;-(
 There's also the issue brought up here that perhaps D is accreting too many 
 kludgy features. Bit is certainly a kludgy feature with too many special 
 cases, and so things would definitely get simpler without it.

Amen to that.
 I definitely get the feeling that D is gaining momentum. Everywhere I go 
 now, people have heard of D. They may not be writing programs in it yet, but 
 they're aware of it and a lot of influential people are keeping tabs on its 
 progress. 

Same here, too. There's pre-dawn light in the horizon, definitely!
 I've been invited to give yet another presentation on D at a major 
 company tomorrow. 

May the Force be with you!
Feb 17 2006
prev sibling next sibling parent Mark D <theomnipotentqatmsn msn.com> writes:
Walter Bright wrote:
 I think the basic type bit has been a failure. It's a substantial increase 
 in the compiler and runtime complexity to support it. Nobody seems happy 
 about bit being a boolean type. There's no reasonable way to take a pointer 
 to a bit, meaning that out and inout bit parameters are inconsistent and 
 kludgy.
 
 Should bit and bit[] be removed before 1.0?
 
 There is a place for bit[] as a library type, though.
 
 So what do people think? 
 
 

I guess I'm in the minority here but I have an affinity for bit and would be sad to see it go. There is something strangely soothing about having a bit variable and knowing that there is actually a bit somewhere out there in the vast expanse of my computer's memory that is fulfilling its purpose in keeping track of a single bit. It is in some way, beautiful. I'm the guy who always had classes in C++ to encapsulate just the number of bits that I wanted in that ever-bizarre now-forgotten syntax. [/EmotionalAppeal] Mark D.
Feb 16 2006
prev sibling next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:dt36tu$1lg3$2 digitaldaemon.com...
I think the basic type bit has been a failure. It's a substantial increase 
in the compiler and runtime complexity to support it. Nobody seems happy 
about bit being a boolean type. There's no reasonable way to take a pointer 
to a bit, meaning that out and inout bit parameters are inconsistent and 
kludgy.

 Should bit and bit[] be removed before 1.0?

 There is a place for bit[] as a library type, though.

 So what do people think?

I only ever use bit for boolean values anyway, so I wouldn't miss it. Besides, the "compiler support" for bit[] has never really extended beyond packing the bits automatically into a word. Were it possible to cast integral types to bit[] and back, it would be a little more useful, but that could be done just as easily and just about as nice-looking with library support. The one thing I like about bit, though, is that it's really quick to type ;)
Feb 16 2006
prev sibling next sibling parent reply "Chris Miller" <chris dprogramming.com> writes:
On Thu, 16 Feb 2006 19:47:21 -0500, Walter Bright  
<newshound digitalmars.com> wrote:

 I think the basic type bit has been a failure. It's a substantial  
 increase
 in the compiler and runtime complexity to support it. Nobody seems happy
 about bit being a boolean type. There's no reasonable way to take a  
 pointer
 to a bit, meaning that out and inout bit parameters are inconsistent and
 kludgy.

 Should bit and bit[] be removed before 1.0?

 There is a place for bit[] as a library type, though.

 So what do people think?

Although I agree that bit[] and bit* have been a failure, bit by itself is pretty nice in my view. Say my largely complex class has 200 bit variables. The compiler packs that into 25 bytes, nice! But now what, we alias it to byte and it becomes 200 bytes.. not so good.. or alias to int and it becomes 800! not good at all. I think bit by itself has its benefits. You may be thinking that keeping bit and removing bit* and bit[] is inconsistent. Well, bits ARE inconsistent, you can't even directly address them, so why should we pretend that bit is consistent. Should I change my 200 bit variables to int and use bit flags and masks? I would in C, but this bit is so much nicer. You could tell me that the new replacement bool type would be smart enough to pack them into bits. How well has that been for C++? I don't actually know, but it seems to me that this is difficult to do effectively because even if you are _able_ (not even directly) to get the address of a bool, it has to put it in at least a byte, but I could be wrong. Plus to do this, code would have to be inserted to pack it correctly, i.e. a simple assignment does magic. Sure the current bit variable has to do this, but it is known and expected. Doesn't it make the new bool look inconsistent? One last thing, bit could still be useful in place of C bit fields and still not need pointer-to-bit: struct foo { union { struct { bit b0; bit b1; bit b2; bit b3; bit b4; bit b5; bit b6; bit b7; } byte by; } } Now about a new bool type. Yes, add one. What should the size be? byte or int; byte has size benefits, int has efficiency benefits. It would probably be best to go with int (actually, ptrdiff_t). Should it be possible that the value be other than true/false? why not! (not asking for a flame war) Just like the current opEquals returns int for efficiency, you can easily convert a value you have at your disposal to a bool (e.g. an int, pointer, HANDLE, etc) without any wasted cycles. But, when comparing with other values, it should only act like true/false. i.e. mybool==true should not be like mybool==1, it should be like mybool!=false, so you see it as having true/false even though it may be any variation of true. Here's my thought on implicit conversions to/from new bool: NO: int -> bool - requires cast, no cycles wasted. NO: pointer -> bool - same as above. YES: bool -> int/byte/long - why not? Allows easy integration with C int as boolean, for one. YES: bool -> bit - why not? They have the same true/false meaning. Also backwards compatible with current bit/bool. NO: bool -> char/etc - no relation, requires cast. Thanks for your time; - Chris
Feb 16 2006
parent reply Oskar Linde <olREM OVEnada.kth.se> writes:
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8Bit

Chris Miller wrote:

 On Thu, 16 Feb 2006 19:47:21 -0500, Walter Bright
 <newshound digitalmars.com> wrote:
 
 I think the basic type bit has been a failure. It's a substantial
 increase
 in the compiler and runtime complexity to support it. Nobody seems happy
 about bit being a boolean type. There's no reasonable way to take a
 pointer
 to a bit, meaning that out and inout bit parameters are inconsistent and
 kludgy.

 Should bit and bit[] be removed before 1.0?

 There is a place for bit[] as a library type, though.

 So what do people think?

Although I agree that bit[] and bit* have been a failure, bit by itself is pretty nice in my view. Say my largely complex class has 200 bit variables. The compiler packs that into 25 bytes, nice! But now what, we alias it to byte and it becomes 200 bytes.. not so good.. or alias to int and it becomes 800! not good at all.

The compiler can not pack those 200 bit variables as long as anything may want to take their addresses. struct Test { bit a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z; } ... assert(Test.sizeof==26);
 Should I change my 200 bit variables to int and use bit flags and masks? I
 would in C, but this bit is so much nicer.

A couple of months ago I implemented simple BitArray StaticBitArray and BitField templates just to get a feeling for how a library replacement for bit[] could work. digitalmars.D.announce/2212 (Searching the newsgroup would turn up other's implementations aswell) The only semantic difference to built in bits is: - StaticBitArray!(n) would become a value type and not a reference type like bit[n] is. (bit[n] behaves like a value type on declaration (allocates storage on the stack/in the struct) but has reference semantics) The advantages over builtin bit arrays are: - foreach with out and inout value. - unaligned slices Just for fun - the BitField hack: typedef void ready, write_protected, loaded, error_code, command; BitField!( ready, 1, write_protected, 1, loaded, 1, error_code, 8, command, 5 ) status; assert(status.sizeof == 2); status.ref!(error_code).opAssign(137); status.ref!(command).opAssign(3); status.ref!(ready).opAssign(1); BitArray something = status.ref!(error_code) ~ status.ref!(command); Attaching the code. (Incomplete, ugly and hackish, but working as a demo) /Oskar
Feb 17 2006
parent reply "Chris Miller" <chris dprogramming.com> writes:
On Fri, 17 Feb 2006 04:09:42 -0500, Oskar Linde <olREM OVEnada.kth.se>  
wrote:

 The compiler can not pack those 200 bit variables as long as anything may
 want to take their addresses.

 struct Test {
         bit a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z;
 }

 ...

 assert(Test.sizeof==26);

I'm not sure that's the reason, it could be due to struct alignment. Do the same with a class (using classinfo.init.sizeof) and it appears packed. If something like align(0) were allowed, they could pack in a struct.
Feb 17 2006
parent reply Oskar Linde <olREM OVEnada.kth.se> writes:
Chris Miller wrote:

 On Fri, 17 Feb 2006 04:09:42 -0500, Oskar Linde <olREM OVEnada.kth.se>
 wrote:
 
 The compiler can not pack those 200 bit variables as long as anything may
 want to take their addresses.

 struct Test {
         bit a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z;
 }

 ...

 assert(Test.sizeof==26);

I'm not sure that's the reason, it could be due to struct alignment. Do the same with a class (using classinfo.init.sizeof) and it appears packed.

Try classinfo.init.length instead. /Oskar
Feb 17 2006
parent "Chris Miller" <chris dprogramming.com> writes:
On Fri, 17 Feb 2006 04:14:37 -0500, Oskar Linde <olREM OVEnada.kth.se>  
wrote:

 Chris Miller wrote:

 On Fri, 17 Feb 2006 04:09:42 -0500, Oskar Linde <olREM OVEnada.kth.se>
 wrote:

 The compiler can not pack those 200 bit variables as long as anything  
 may
 want to take their addresses.

 struct Test {
         bit a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z;
 }

 ...

 assert(Test.sizeof==26);

I'm not sure that's the reason, it could be due to struct alignment. Do the same with a class (using classinfo.init.sizeof) and it appears packed.

Try classinfo.init.length instead. /Oskar

Oops! well, if bit variables were never intended to be packed, then I'm all for removing bit.
Feb 17 2006
prev sibling next sibling parent "Matthew" <matthew hat.stlsoft.dot.org> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message
news:dt36tu$1lg3$2 digitaldaemon.com...
 I think the basic type bit has been a failure. It's a substantial increase
 in the compiler and runtime complexity to support it. Nobody seems happy
 about bit being a boolean type. There's no reasonable way to take a

 to a bit, meaning that out and inout bit parameters are inconsistent and
 kludgy.

 Should bit and bit[] be removed before 1.0?

 There is a place for bit[] as a library type, though.

 So what do people think?

Strongly agree.
Feb 16 2006
prev sibling next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:
 I think the basic type bit has been a failure. It's a substantial increase 
 in the compiler and runtime complexity to support it. Nobody seems happy 
 about bit being a boolean type. There's no reasonable way to take a pointer 
 to a bit, meaning that out and inout bit parameters are inconsistent and 
 kludgy.
 
 Should bit and bit[] be removed before 1.0?

Yes! But I have one question: what will happen to bool, will it now be an alias to int? Will we get a real bool type? (Will if and while still expect int or will they expect bool?)
 
 There is a place for bit[] as a library type, though.

That is where it belongs since it is hard to implement in the language keeping it consistent with other array types.
Feb 17 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message 
news:dt45me$2eca$1 digitaldaemon.com...
 Walter Bright wrote:
 Should bit and bit[] be removed before 1.0?

alias to int? Will we get a real bool type? (Will if and while still expect int or will they expect bool?)

I was thinking of making bool a keyword and basic type along the lines of bool in C++.
Feb 17 2006
next sibling parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:
 "Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message 
 news:dt45me$2eca$1 digitaldaemon.com...
 
Walter Bright wrote:

Should bit and bit[] be removed before 1.0?

Yes! But I have one question: what will happen to bool, will it now be an alias to int? Will we get a real bool type? (Will if and while still expect int or will they expect bool?)

I was thinking of making bool a keyword and basic type along the lines of bool in C++.

Great! Not ideal but much much better than now.
Feb 17 2006
prev sibling next sibling parent "Derek Parnell" <derek psych.ward> writes:
On Sat, 18 Feb 2006 03:17:18 +1100, Walter Bright  
<newshound digitalmars.com> wrote:

 "Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message
 news:dt45me$2eca$1 digitaldaemon.com...
 Walter Bright wrote:
 Should bit and bit[] be removed before 1.0?

an alias to int? Will we get a real bool type? (Will if and while still expect int or will they expect bool?)

I was thinking of making bool a keyword and basic type along the lines of bool in C++.

Oh come on, you can do better than that. -- Derek Parnell Melbourne, Australia
Feb 17 2006
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter Bright wrote:

Yes! But I have one question: what will happen to bool, will it now be an 
alias to int? Will we get a real bool type? (Will if and while still 
expect int or will they expect bool?)

I was thinking of making bool a keyword and basic type along the lines of bool in C++.

I thought not having a boolean type was part of D's "personality". Wonder what will be next ??? A std.string library class perhaps... :-O --anders
Feb 18 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Anders F Bj÷rklund" <afb algonet.se> wrote in message 
news:dt75m2$243m$2 digitaldaemon.com...
 Walter Bright wrote:
 I was thinking of making bool a keyword and basic type along the lines of 
 bool in C++.


Boolean was redundant to the bit type.
Feb 18 2006
next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Sun, 19 Feb 2006 07:39:18 +1100, Walter Bright  
<newshound digitalmars.com> wrote:

 "Anders F Bj├Ârklund" <afb algonet.se> wrote in message
 news:dt75m2$243m$2 digitaldaemon.com...
 Walter Bright wrote:
 I was thinking of making bool a keyword and basic type along the lines  
 of
 bool in C++.


Boolean was redundant to the bit type.

Wrong! That statement implies that the entire requirements of a correct 'boolean' type is met by the behaviour of the 'bit' type. And that is demonstrably incorrect. -- Derek Parnell Melbourne, Australia
Feb 18 2006
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:op.s46t2hmc6b8z09 ginger.vic.bigpond.net.au...
 Wrong! That statement implies that the entire requirements of a correct 
 'boolean' type is met by the behaviour of the 'bit' type. And that is 
 demonstrably incorrect.

Woah, woah, woah, take it _down_ a notch, Derek! This is a _boolean data type_ we're talking about here, not world politics! ;)
Feb 18 2006
parent "Derek Parnell" <derek psych.ward> writes:
On Sun, 19 Feb 2006 11:41:49 +1100, Jarrett Billingsley  
<kb3ctd2 yahoo.com> wrote:

 "Derek Parnell" <derek psych.ward> wrote in message
 news:op.s46t2hmc6b8z09 ginger.vic.bigpond.net.au...
 Wrong! That statement implies that the entire requirements of a correct
 'boolean' type is met by the behaviour of the 'bit' type. And that is
 demonstrably incorrect.

Woah, woah, woah, take it _down_ a notch, Derek! This is a _boolean data type_ we're talking about here, not world politics! ;)

Huh? There's a difference? I'm spending too much time here I think. -- Derek Parnell Melbourne, Australia
Feb 18 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:op.s46t2hmc6b8z09 ginger.vic.bigpond.net.au...
 On Sun, 19 Feb 2006 07:39:18 +1100, Walter Bright 
 <newshound digitalmars.com> wrote:

 "Anders F Bj÷rklund" <afb algonet.se> wrote in message
 news:dt75m2$243m$2 digitaldaemon.com...
 Walter Bright wrote:
 I was thinking of making bool a keyword and basic type along the lines 
 of
 bool in C++.


Boolean was redundant to the bit type.

Wrong! That statement implies that the entire requirements of a correct 'boolean' type is met by the behaviour of the 'bit' type. And that is demonstrably incorrect.

It did nearly every item on your list. Adding another basic type that overlapped 98% with another basic type is just not a good idea. But absent that other type, then it does become a good idea.
Feb 19 2006
parent "Derek Parnell" <derek psych.ward> writes:
On Sun, 19 Feb 2006 19:10:23 +1100, Walter Bright  
<newshound digitalmars.com> wrote:

 "Derek Parnell" <derek psych.ward> wrote in message
 news:op.s46t2hmc6b8z09 ginger.vic.bigpond.net.au...
 On Sun, 19 Feb 2006 07:39:18 +1100, Walter Bright
 <newshound digitalmars.com> wrote:

 "Anders F Bj├Ârklund" <afb algonet.se> wrote in message
 news:dt75m2$243m$2 digitaldaemon.com...
 Walter Bright wrote:
 I was thinking of making bool a keyword and basic type along the  
 lines
 of
 bool in C++.


Boolean was redundant to the bit type.

Wrong! That statement implies that the entire requirements of a correct 'boolean' type is met by the behaviour of the 'bit' type. And that is demonstrably incorrect.

It did nearly every item on your list. Adding another basic type that overlapped 98% with another basic type is just not a good idea. But absent that other type, then it does become a good idea.

I note my "entire" and your "nearly" <g>. But thank you, Walter. What didn't you deem worthy? By the way, is there anything else I can 'specify' for you? -- Derek Parnell Melbourne, Australia
Feb 19 2006
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter Bright wrote:

I thought not having a boolean type was part of D's "personality".

Boolean was redundant to the bit type.

I meant the part where sometimes a "byte" was the best boolean type, and sometimes an "int" was the best match (for speed, for instance). Where "bit" just happened to be a default match, for the bool alias. But I will just go with the flow, as I'm not using "raw" bit or bit[]. --anders
Feb 18 2006
prev sibling next sibling parent Alexander Panek <alexander.panek brainsware.org> writes:
Walter Bright wrote:
 I think the basic type bit has been a failure. It's a substantial increase 
 in the compiler and runtime complexity to support it. Nobody seems happy 
 about bit being a boolean type. There's no reasonable way to take a pointer 
 to a bit, meaning that out and inout bit parameters are inconsistent and 
 kludgy.
 
 Should bit and bit[] be removed before 1.0?
 
 There is a place for bit[] as a library type, though.
 
 So what do people think? 
 
 

A bit type is a bit weird, but as long as there'll be a library replacement available, I agree with the removal, though it doesn't matter what I agree or not. *nods* Regards, Alex
Feb 17 2006
prev sibling next sibling parent Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Walter Bright wrote:
 I think the basic type bit has been a failure. It's a substantial increase 
 in the compiler and runtime complexity to support it. Nobody seems happy 
 about bit being a boolean type. There's no reasonable way to take a pointer 
 to a bit, meaning that out and inout bit parameters are inconsistent and 
 kludgy.
 
 Should bit and bit[] be removed before 1.0?
 
 There is a place for bit[] as a library type, though.
 
 So what do people think? 
 
 

Yes, axe it. And we should take this opportunity to make a better bool. I make mine's Derek's comments about bool. And please, *please*, do not keep yourself from doing good changes to the languages because of backwards compatibility, especially if the language is still in development. We should try to get the best D as possible out there, and it's not good if we start getting hampered already with the same design impediments that plague C/C++ such as backwards compatibility. Not that we should be changing D all the time, but keep this in mind. -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Feb 17 2006
prev sibling next sibling parent clayasaurus <clayasaurus gmail.com> writes:
I don't use it.

Walter Bright wrote:
 I think the basic type bit has been a failure. It's a substantial increase 
 in the compiler and runtime complexity to support it. Nobody seems happy 
 about bit being a boolean type. There's no reasonable way to take a pointer 
 to a bit, meaning that out and inout bit parameters are inconsistent and 
 kludgy.
 
 Should bit and bit[] be removed before 1.0?
 
 There is a place for bit[] as a library type, though.
 
 So what do people think? 
 
 

Feb 17 2006
prev sibling next sibling parent BCS <BCS_member pathlink.com> writes:
In article <dt36tu$1lg3$2 digitaldaemon.com>, Walter Bright says...
I think the basic type bit has been a failure. It's a substantial increase 
in the compiler and runtime complexity to support it. Nobody seems happy 
about bit being a boolean type. There's no reasonable way to take a pointer 
to a bit, meaning that out and inout bit parameters are inconsistent and 
kludgy.

Should bit and bit[] be removed before 1.0?

There is a place for bit[] as a library type, though.

So what do people think? 

If overloding of the opFunction for typedefs were allowed then bit[] could be done as a typedef (this would also permit lots of other cool things)
Feb 17 2006
prev sibling next sibling parent Les Baker <les_baker REMOVEbellsouthREMOVE.net> writes:
Walter Bright wrote:
 I think the basic type bit has been a failure. It's a substantial increase 
 in the compiler and runtime complexity to support it. Nobody seems happy 
 about bit being a boolean type. There's no reasonable way to take a pointer 
 to a bit, meaning that out and inout bit parameters are inconsistent and 
 kludgy.
 
 Should bit and bit[] be removed before 1.0?
 
 There is a place for bit[] as a library type, though.
 
 So what do people think?  

Another definate Yes vote for removal (and replacement with a true boolean type) here! (From a long-time newsgroup lurker who remembers the bit v bool debate) Les Baker
Feb 17 2006
prev sibling next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter Bright wrote:

 I think the basic type bit has been a failure. It's a substantial increase 
 in the compiler and runtime complexity to support it. Nobody seems happy 
 about bit being a boolean type. There's no reasonable way to take a pointer 
 to a bit, meaning that out and inout bit parameters are inconsistent and 
 kludgy.

You could always rename bit to _Bool instead... :-) --anders
Feb 18 2006
prev sibling next sibling parent Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
Walter Bright wrote:
 Should bit and bit[] be removed before 1.0?

Feb 18 2006
prev sibling next sibling parent reply Kevin Bealer <Kevin_member pathlink.com> writes:
In article <dt36tu$1lg3$2 digitaldaemon.com>, Walter Bright says...
I think the basic type bit has been a failure. It's a substantial increase 
in the compiler and runtime complexity to support it. Nobody seems happy 
about bit being a boolean type. There's no reasonable way to take a pointer 
to a bit, meaning that out and inout bit parameters are inconsistent and 
kludgy.

Should bit and bit[] be removed before 1.0?

There is a place for bit[] as a library type, though.

So what do people think? 

If it's that complex to implement bit[], a library seems fine to me. But if you're tossing "bit" for being ugly, it should be to replace it with something cleaner, with equal or better performance. Is there a replacement for bit that works as well and doesn't require implicit (x ? 1 : 0) branches inserted everywhere? I think the worst thing would be to have a language designed by the influence of the people who complained. I think Java got rid of unsigned types for this reason. Every CPU you can buy supports unsigned, but Java can't. *All* low level programming has to deal with ugly, machine oriented realities. This will always bother some people. But I think 80% of user complaints are driven not by real design motivations, but by the "surprise" principle: "Why doesn't it work the way I guessed it would?" This principle makes perfect sense at the high level (web page) but not at the hardware level. Software can be beautiful, but not "too beautiful for this world". If D gets the low level stuff right, it *has* to have ugly parts that are fast a la C rather than pretty parts that are slow al la Java, in at least a few, unremovable cases. Is "bit" or "bool" one of these? Kevin
Feb 22 2006
next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Kevin Bealer" <Kevin_member pathlink.com> wrote in message 
news:dtjekm$126q$1 digitaldaemon.com...
 I think the worst thing would be to have a language designed by the 
 influence of
 the people who complained.

LOL. I agree.
 *All* low level programming has to deal with ugly, machine oriented 
 realities.
 This will always bother some people.

Yes. D has to work with the reality. Java got into a lot of trouble with floating point because the spec ignored the reality of FPU hardware. The spec got subsequently revised.
 Is "bit" or "bool" one of these?

It turns out that a BitArray struct can pretty much cover nearly all the uses for bit[].
Feb 23 2006
parent Kevin Bealer <Kevin_member pathlink.com> writes:
In article <dtlst4$2fic$3 digitaldaemon.com>, Walter Bright says...
"Kevin Bealer" <Kevin_member pathlink.com> wrote in message 
news:dtjekm$126q$1 digitaldaemon.com...
 I think the worst thing would be to have a language designed by the 
 influence of
 the people who complained.

LOL. I agree.
 *All* low level programming has to deal with ugly, machine oriented 
 realities.
 This will always bother some people.

Yes. D has to work with the reality. Java got into a lot of trouble with floating point because the spec ignored the reality of FPU hardware. The spec got subsequently revised.
 Is "bit" or "bool" one of these?

It turns out that a BitArray struct can pretty much cover nearly all the uses for bit[].

I don't use it much in D right now, so this isn't really a request, but as a related story from C++: I used vector<bool> in C++ (at work) and discovered that it is much slower to use vector<bool> than my own vector<int> wrapper, with specialized bit setter / getter / scanner methods. I was surprised at this since I thought C++ could / did override all this stuff for perf. reasons. (Isn't STL supposed to be a high performance design?) The problem in C++ is that all operations over the collection, are defined in terms of operations with iterators, and vector<bool> doesn't (or can't?) change this aspect. For instance, resizing a C++ vector<bool> does a bit-by-bit copy. So it is something like 32 times as slow as memcpy(), for a number of common operations. This affected us, since we were trying to work with vectors of millions of bits, literally trying to compute ORs and ANDs with bit sets that range up to around a max of 50 million elements (~6 megabytes). [D has the operators to do this the right way, but unfortunately C++ did not.] One thing I often needed (when I was using vector<bool>), that I don't see in the D version was a way to scan forward for the next 1 bit. I would suggest an interface like this: ptrdiff_t BitArray.findValue(size_t start_point, size_t end_point, bool find_this); Or: ptrdiff_t BitArray.findValue(size_t start_point, size_t end_point, BitArray find_this); Since these interfaces could find values much faster than iteration with something like opIndex() or opApply(). Kevin
Feb 27 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
Kevin Bealer wrote:
 
 But I think 80% of user complaints are driven not by real design motivations,
 but by the "surprise" principle:  "Why doesn't it work the way I guessed it
 would?"

There's something to be said for predictability. It doesn't have to be a slippery slope :-)
 This principle makes perfect sense at the high level (web page) but not at the
 hardware level.  Software can be beautiful, but not "too beautiful for this
 world".  If D gets the low level stuff right, it *has* to have ugly parts that
 are fast a la C rather than pretty parts that are slow al la Java, in at least
a
 few, unremovable cases.
 
 Is "bit" or "bool" one of these?

I don't think so. I find that the inability to address array-stored bits causes me more trouble than is worth the benefits. Particularly considering that an equivalent library class could be created which provides similar performance characteristics. Sean
Feb 23 2006
parent reply Kevin Bealer <Kevin_member pathlink.com> writes:
In article <dtlvp3$2isk$1 digitaldaemon.com>, Sean Kelly says...
Kevin Bealer wrote:
 
 But I think 80% of user complaints are driven not by real design motivations,
 but by the "surprise" principle:  "Why doesn't it work the way I guessed it
 would?"

There's something to be said for predictability. It doesn't have to be a slippery slope :-)

I've thought about this more, and I mostly agree... But there are several reasons for such predictions. These come to mind: A. My other language does X. B. Java, C or C++ does X (special case, as these are sort of 'siblings' to D, at least in the mind of users. C. Mathematicians do X. D. D does X in this other part over here. E. WWDEKD? What would Donald E. Knuth do? :) F. I just expected it out of the blue - I've never programmed before. G. I just expected it out of the blue - I worked in assembler for years. (A) and (C) are not important to me. The (D) variant is the most important to me. (F) is semi-important but is the "web page" level of design, not great for systems languages. (G) is relevant for performance and hardware interfacing cases especially. (B) is relevant, but most of what we argue varies between Java, C, and C++, so what we see is often (B) vs. (B), argued from different sides. (E) is a religious question, as always... ;) Kevin
 This principle makes perfect sense at the high level (web page) but not at the
 hardware level.  Software can be beautiful, but not "too beautiful for this
 world".  If D gets the low level stuff right, it *has* to have ugly parts that
 are fast a la C rather than pretty parts that are slow al la Java, in at least
a
 few, unremovable cases.
 
 Is "bit" or "bool" one of these?

I don't think so. I find that the inability to address array-stored bits causes me more trouble than is worth the benefits. Particularly considering that an equivalent library class could be created which provides similar performance characteristics. Sean

Feb 27 2006
parent Georg Wrede <georg.wrede nospam.org> writes:
Kevin Bealer wrote:
 (E) is a religious question, as always... ;)

He ain't dead yet.
Feb 27 2006
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:
 I think the basic type bit has been a failure. It's a substantial increase 
 in the compiler and runtime complexity to support it. Nobody seems happy 
 about bit being a boolean type. There's no reasonable way to take a pointer 
 to a bit, meaning that out and inout bit parameters are inconsistent and 
 kludgy.
 
 Should bit and bit[] be removed before 1.0?
 
 There is a place for bit[] as a library type, though.
 
 So what do people think? 

Something I didn't see anyone mention is the fact that 'bit' isn't really a native CPU type. x86 doesn't have any instructions that operate on bits per se, except for the carry flag. Everything else is operations on bits within integers. Bits are like quarks: everything is made out of them, but you can never see one on its own. I think D has been pretending that there's such a thing as an isolated bit, the same mistake that C++ made with vector<bool>. It's an illusion that's too costly to maintain.
Feb 24 2006
next sibling parent reply James Dunne <james.jdunne gmail.com> writes:
Don Clugston wrote:
 Walter Bright wrote:
 
 I think the basic type bit has been a failure. It's a substantial 
 increase in the compiler and runtime complexity to support it. Nobody 
 seems happy about bit being a boolean type. There's no reasonable way 
 to take a pointer to a bit, meaning that out and inout bit parameters 
 are inconsistent and kludgy.

 Should bit and bit[] be removed before 1.0?

 There is a place for bit[] as a library type, though.

 So what do people think? 

Something I didn't see anyone mention is the fact that 'bit' isn't really a native CPU type. x86 doesn't have any instructions that operate on bits per se, except for the carry flag. Everything else is operations on bits within integers. Bits are like quarks: everything is made out of them, but you can never see one on its own. I think D has been pretending that there's such a thing as an isolated bit, the same mistake that C++ made with vector<bool>. It's an illusion that's too costly to maintain.

Can someone explain the vector<bool> problem? I thought C++'s bool resolved to an integer of the native word size of the machine. Conceptually, I can't see a problem here, but then again I've not cared to do much C++ coding in a while. =P -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O M-- V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e h>--->++ r+++ y+++ ------END GEEK CODE BLOCK------ James Dunne
Feb 24 2006
parent Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
James Dunne wrote:

 Can someone explain the vector<bool> problem?  I thought C++'s bool 
 resolved to an integer of the native word size of the machine.

It does, but the standard specifies (or at least used to specify) vector<bool> as a specialization that keeps a packed representation internally. This leads to many inconsistencies similar to bit[] in D. I do not know what the C++ committee has since decided regarding this. /Oskar
Feb 24 2006
prev sibling next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Don Clugston wrote:

 Something I didn't see anyone mention is the fact that 'bit' isn't 
 really a native CPU type. x86 doesn't have any instructions that operate 
 on bits per se, except for the carry flag. Everything else is operations 
 on bits within integers. Bits are like quarks: everything is made out of 
 them, but you can never see one on its own.

Not the "fundamental data type" then ? ;-) Even more confusing was/is that the bit type in D acts like a boolean - and not like an integer. I for one won't be sad to see it go... (replacing "bit" with "bool")
 I think D has been pretending that there's such a thing as an isolated 
 bit, the same mistake that C++ made with vector<bool>. It's an illusion 
 that's too costly to maintain.

I'm not sure that switching bool[] over, from bit[] to byte[], would be that big a "waste", even if it's up to 8 times bigger ? And like been said earlier, there are plenty of BitArray classes. --anders
Feb 24 2006
prev sibling parent pragma <pragma_member pathlink.com> writes:
In article <dtmh75$nn1$1 digitaldaemon.com>, Don Clugston says...
Walter Bright wrote:
 I think the basic type bit has been a failure. It's a substantial increase 
 in the compiler and runtime complexity to support it. Nobody seems happy 
 about bit being a boolean type. There's no reasonable way to take a pointer 
 to a bit, meaning that out and inout bit parameters are inconsistent and 
 kludgy.
 
 Should bit and bit[] be removed before 1.0?
 
 There is a place for bit[] as a library type, though.
 
 So what do people think? 

Something I didn't see anyone mention is the fact that 'bit' isn't really a native CPU type. x86 doesn't have any instructions that operate on bits per se, except for the carry flag. Everything else is operations on bits within integers. Bits are like quarks: everything is made out of them, but you can never see one on its own. I think D has been pretending that there's such a thing as an isolated bit, the same mistake that C++ made with vector<bool>. It's an illusion that's too costly to maintain.

Good point. I'd even go as far to say that even for embedded micro-controllers (like Microchip PICs for example), I/O pins are managed as groups of 4, 8 or 16 to a 'port' at the assembler code level. So the bit[] paradigm wouldn't be a big gain for that paradigm even though you wind up manipulating individual bits a fair amount. The only thing that bit[] had going for it was the potential for iteration via foreach(). Since most uses of bit[] would map well to a single uint or ulong, you can cover the bases with good old-fashioned flags, at the cost of some minor syntax and value changes (powers-of-two versus bit indexing). - Eric Anderton
Feb 24 2006
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:
 I think the basic type bit has been a failure. It's a substantial increase 
 in the compiler and runtime complexity to support it. Nobody seems happy 
 about bit being a boolean type. There's no reasonable way to take a pointer 
 to a bit, meaning that out and inout bit parameters are inconsistent and 
 kludgy.
 
 Should bit and bit[] be removed before 1.0?
 
 There is a place for bit[] as a library type, though.
 
 So what do people think?

I was just thinking about my BitArray stuff in my utility library http://pr.stewartsplace.org.uk/d/sutil/ and looking again at how it's implemented. It doesn't use D's bit arrays internally, so the only implication for the library really is getting rid of the conversions to and from them. (And debugging the big-endian implementation logic!) But it's worth looking at it before reinventing the wheel, at least for those of you who haven't already reinvented the wheel.... :-) Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Feb 24 2006