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
 }


  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?


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?


 
 


[snip]

 
 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


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.


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:
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. 
http://www.digitalmars.com/drn-bin/wwwnews?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


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?


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?


 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++.
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?


 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++.


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++.


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


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++.


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


 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++.


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


 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++.


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


 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?


+1
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