"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:c8vg4g$r6t$1@digitaldaemon.com...
> Matthew wrote:
> > I don't propose any change in bit whatsoever, save that true and false may no longer be implicitly used by it, or any other integral type. I want a boolean type that is:
> >
> > - not implicitly convertible to any other type
> > - is the type of all conditional expressions
> > - is of variable size, according to context. It would default to a (time)
> > efficiently representation as the same size as the architecture, e.g.
32-bits, in
> > order to avoid the costs in the implicit "b = !b ? 0 : 1" evaluation.
However, it
> > could be align'd to any alignment, right down to 1-bit, according to the
user's
> > decision. The compiler will handle all issues regarding accessing by pointer. (The one issue here is that accessing a bit by pointer is tricky, but could
be
> > achieve by having a boolean ptr as a two-value entity. Not sure about this
one as
> > yet, however ...)
>
> For what it's worth, I completely agree with Matthew. At least with his first two points.
>
> I'm not sure if the size saving argument of point 3 really justifies the complexity of having a type with a variable size, though. My gut tells me that this kind of thing can cause lots of headaches and bug opportunities, both for the compiler writer and for the programmer who uses it.
>
> I'd be happy if bool would be implemented(!) as an int, where !=0 is the same as true and 0 is false. So it basically means that the compiler has to translate bool==true to bool!=0 instead of bool==1 and boolA==boolB to a suitable construct that ensures correctness. Otherwise it could internally be treated as a typedef'ed int without arithmetic operations. Even Walter could use such a bool type ;) (he currently uses int instead of bit because int is faster).
>
> The need to conserve memory for bools is so rare that I think this would
> be sufficient and it has the added benefit of being dead simple. If size
> should really become an issue (for example with huge bool arrays) the
> programmer still has the option to use bit instead. He won't have the
> advantages of a real bool type then, but at least he will be aware of
> the issues (since he explicitly chose bit) and can deal with them properly.
>
> Note that I'm only talking about the internal implementation here. Bool should still be a completely independent type, of course, with no implicit conversions.

Actually, I completely agree with you. I was just pandering to the violent objectors, if they're still involving themselves, that came out the last time I asked for sizeof(boolean) to be sizeof(register), late last year.

James McComb wrote:

> J Anderson wrote:
>
>> I'm against having two types.  Bit and bool overlap on just about all functionality.
>
>
> I understand what you mean, but strictly speaking, if bit is arithmetic and bool is logical, they don't overlap at all.
>
> Interface for bit: +, -, * , / etc.
> Interface for bool: &&, || etc.
>
> James McComb

So a bit isn't a integer like Matthew suggests then?

-- 
-Anderson: http://badmama.com.au/~anderson/

>- not implicitly convertible to any other type

Nor _from_ any type.

On Tue, 25 May 2004 19:22:30 +0800, J Anderson wrote:

> Arcane Jill wrote:
> 
>>Personally, I would favor two distinct types: bit and bool, with bit being considered an arithmetic type (like a one bit wide unsigned integer), and bool able only to take values true and false.
>>
> I'm against having two types.  Bit and bool overlap on just about all functionality.  However I do think bit should work for all cases a bool would work.

Well actually that turns out not to be the case.

 int a;
 bit b;
 bool c;
 int d;


 a = 5;
 b = 1;
 c = true;

 d = a + b; // Ok, makes sense.
 d = a + c; // Not ok. Does not make sense.

 d = a + cast(bit)c; // Well if you real have to...

that last line is really another way of saying ...

 d = a + (c ? 1 : 0);


-- 
Derek
26/May/04 9:30:45 AM

> d = a + cast(bit)c; // Well if you real have to...
>
>that last line is really another way of saying ...
>
> d = a + (c ? 1 : 0);
>

No, the former line is evil, and the latter is preferred.

The former would be kinda like trying to do
int x = cast(int) "123" ;
what are you going to get? Certainly not the integer value 123 which appears to
be the goal. (Granted you may want to do this some time for some reason, I
have.)

<soapbox>
Although I'm sure that if boolean is changed in the language as proposed it will
be implemented in such a way that the former will work, but it's best not to
expect it to. Why demand that boolean be a true (whoops) boolean and then allow
non-boolean access thereto? There should be no meaningful way to cast to or from
boolean, only a test should work. Think of the equality, relational, and trinary
operators as "casts" for boolean.

Part of the goal (in my mind anyway) is to retrain C programmers from thinking
of booleans as integers. Booleans are _not_ numeric values!
</soapbox>

On Wed, 26 May 2004 00:37:38 +0000 (UTC), Juan C wrote:

>> d = a + cast(bit)c; // Well if you real have to...
>>
>>that last line is really another way of saying ...
>>
>> d = a + (c ? 1 : 0);
>>
> 
> No, the former line is evil, and the latter is preferred.

I agree. I was just trying to suggest a compromise, or concession, to help get the bool/bit/int differentiation across the line. ;-)


> The former would be kinda like trying to do
> int x = cast(int) "123" ;
> what are you going to get? Certainly not the integer value 123 which appears to
> be the goal. (Granted you may want to do this some time for some reason, I
> have.)

Yeah, we all know what you intend here, so maybe this is not such an 'evil' example. The 'cast' is explicitly saying "please convert the subject into the format that I'm specifying". In your example, convert "123" into an integer.

> <soapbox>
> Although I'm sure that if boolean is changed in the language as proposed it will
> be implemented in such a way that the former will work, but it's best not to
> expect it to. Why demand that boolean be a true (whoops) boolean and then allow
> non-boolean access thereto? There should be no meaningful way to cast to or from
> boolean, only a test should work. Think of the equality, relational, and trinary
> operators as "casts" for boolean.
> 
> Part of the goal (in my mind anyway) is to retrain C programmers from thinking
> of booleans as integers. Booleans are _not_ numeric values!
> </soapbox>

Not a bad goal at all; sign me up for the Cause.
-- 
Derek
26/May/04 10:44:50 AM

"Juan C" <Juan_member@pathlink.com> wrote in message news:c90osi$2rmp$1@digitaldaemon.com...
> > d = a + cast(bit)c; // Well if you real have to...
> >
> >that last line is really another way of saying ...
> >
> > d = a + (c ? 1 : 0);
> >
>
> No, the former line is evil, and the latter is preferred.
>
> The former would be kinda like trying to do
> int x = cast(int) "123" ;
> what are you going to get? Certainly not the integer value 123 which appears to
> be the goal. (Granted you may want to do this some time for some reason, I
> have.)
>
> <soapbox>
> Although I'm sure that if boolean is changed in the language as proposed it
will
> be implemented in such a way that the former will work, but it's best not to expect it to. Why demand that boolean be a true (whoops) boolean and then allow non-boolean access thereto? There should be no meaningful way to cast to or
from
> boolean, only a test should work. Think of the equality, relational, and
trinary
> operators as "casts" for boolean.
>
> Part of the goal (in my mind anyway) is to retrain C programmers from thinking
> of booleans as integers. Booleans are _not_ numeric values!
> </soapbox>

Hear, hear!

On Wed, 26 May 2004 10:49:45 +1000, Derek Parnell <derek@psych.ward> wrote:
>> The former would be kinda like trying to do
>> int x = cast(int) "123" ;
>> what are you going to get? Certainly not the integer value 123 which appears to
>> be the goal. (Granted you may want to do this some time for some reason, I
>> have.)
>
> Yeah, we all know what you intend here, so maybe this is not such an 'evil'
> example. The 'cast' is explicitly saying "please convert the subject into
> the format that I'm specifying". In your example, convert "123" into an
> integer.

OR.. is x supposed to be set to the bits involved in the ascii characters "123" in that order?

This is not such a silly suggestion if you're writing a text encryption routine that swaps bits on 32 bit boundaries.

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

J Anderson wrote:

>> Interface for bit: +, -, * , / etc.
>> Interface for bool: &&, || etc.
> 
> So a bit isn't a integer like Matthew suggests then?

Yes, I think that bit should be a type of integer.

A bit should be an integer with a value ranging from 0 to 1 inclusive.
It could be safely promoted to larger integer types.

A bool should be a type with the non-numeric values true and false.
An explicit cast would be required to convert to and from bool.

I believe Arcane Jill is advocating the same thing.

James McComb

James McComb wrote:

> A bit should be an integer with a value ranging from 0 to 1 inclusive.
> It could be safely promoted to larger integer types.
> 
> A bool should be a type with the non-numeric values true and false.
> An explicit cast would be required to convert to and from bool.

In addition, I'm also happy with the idea of bool being implemented internally as an int.

James McComb