Walter wrote:

> Your points are well taken. One of my problems with a separate bool type is that a bool can have only two values, yet it is represented by a type that can contain many values. It just never seems to feel right. -Walter
>

May I politely remark that you are taking an x86-centric view of the world here? :-) For instance, consider IA-64. The IA-64 has 64 1-bit predicate registers. These are real bools. Well, even in the x86 world, it's not a big deal to allocate one bit per bool in a shared byte, and to have some hint in your register/stack allocator to ensure that bools tend to be packed together.

Christophe

Walter wrote:
> Your points are well taken. One of my problems with a separate bool type is
> that a bool can have only two values, yet it is represented by a type that
> can contain many values. It just never seems to feel right. -Walter
> 
> Russ Lewis wrote in message <3B7D5282.5AF7C365@deming-os.org>...
> 
...
Well, you could define 0 as false, 255 as true, and the values in between as values of maybe.  That would use all the bits (maybe).

This would allow comparison to be defined, but what would be the results of a branch?  Take both branches on different processors?  Flip a random number generator?

Alternatively, a bool could be defined as a bit vector of length 8(?), with the standard operations addressing the 0th element.  Or maybe the high bit.  (Are those the same, or different?)

I'm not sure what value either of these would have.  The bit vector seems cheapest.  The only additional operation needed if rotate, and that's usually an assembler primitive.

	Well, I can't offer any technical reasons but I agree with your feeling
here.  I find the C style logical operator very powerful.  Frankly I
wish you would add perl style 'until' and 'unless' structures as well as
the ability to have a statement followed by a loop or conditional
statement since I find it to be very expressive.  I find these help make
intentions clearer in certain cases.  I had no good technical reason for
that either so I head off asking.
	In any case, I'm glad to see labeled breaks and continues, a redo might
be nice to avoid a goto, and I hope you keep the logical ops I know and
love.  They allow me to say more meaningful things with less verbage.

Dan

Walter wrote:
> 
> Your points are well taken. One of my problems with a separate bool type is that a bool can have only two values, yet it is represented by a type that can contain many values. It just never seems to feel right. -Walter
> 
> Russ Lewis wrote in message <3B7D5282.5AF7C365@deming-os.org>...
> >I would suggest that bool NOT be an integer type.  All conditional tests should return bool and all conditional expressions should only accept bools, not integers.
> >
> >That would mean no casts (implicit or explicit) from one to the other. The general idea is to prevent this classic bug:
> >
> >int a,b;
> >if( a = b) ...
> >
> >This returns an integer which is passed to the if.  Some compilers notice this and issue warnings, but that solution is not necessarily reliable and it increases compiler complexity.
> >
> >Making bool's and int's different types also reduces the number of operators we need.  The &&, ||, and ~ operators could all be deprecated:
> >
> >bool & bool        logical  AND
> >bool | bool          logical OR
> >!bool                  logical NOT
> >
> >int & int              bitwise AND
> >int | int                bitwise OR
> >!int                     bitwise NOT
> >
> >I suggest the & and | operators because they are shorter to type, and the ! operator over the ~ operator because it is better known.
> >

Russ Lewis <russ@deming-os.org> writes:

> I would suggest that bool NOT be an integer type.

Yes, this elimenates several common errors often encountered in C source code.

> Making bool's and int's different types also reduces the number of operators we need.  The &&, ||, and ~ operators could all be deprecated:
> 
> bool & bool        logical  AND
> bool | bool          logical OR
> !bool                  logical NOT

What about short-circuit evaluation?  Perhaps this should be provided by a non-overloadable operator.

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

"Walter" <walter@digitalmars.com> writes:

> Your points are well taken. One of my problems with a separate bool type is that a bool can have only two values, yet it is represented by a type that can contain many values. It just never seems to feel right.

On many machines, quite a lot of the basic integer types are represented using full registers, with superfluous bits.  Why do you have problems with that?

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

>
> On many machines, quite a lot of the basic integer types are represented using full registers, with superfluous bits.  Why do you have problems with that?
>
> --


Because the logistics of bool are different than the logistics of integer. Integer has (usually) 2^32 individual values, each with their own unique meaning.  The concept of bool means that the value of the variable is either "false" or "true".  With an integer implementation, you change the concept of the bool to "false" or "not false".

Represent a bool with individual bits either on or off, and you can have 8 bools take up 1 byte, instead of 8 bytes, easy to implement with D's built in bit type and bit array type.

Just an issue of semantics.  Proper semantics can help you "feel right"   :)

-Brady

Florian Weimer wrote:

> Russ Lewis <russ@deming-os.org> writes:
>
> > I would suggest that bool NOT be an integer type.
>
> Yes, this elimenates several common errors often encountered in C source code.
>
> > Making bool's and int's different types also reduces the number of operators we need.  The &&, ||, and ~ operators could all be deprecated:
> >
> > bool & bool        logical  AND
> > bool | bool          logical OR
> > !bool                  logical NOT
>
> What about short-circuit evaluation?  Perhaps this should be provided by a non-overloadable operator.

Short-circuit evaluation is still possible, provided that both sides of the operator return bools.

Ofc, short-circuit error handling wouldn't work:

doStuff() || exit(1);

but that's done better with exceptions anyhow.

Russ Lewis <russ@deming-os.org> writes:

> > > bool & bool        logical  AND
> > > bool | bool          logical OR
> > > !bool                  logical NOT
> >
> > What about short-circuit evaluation?  Perhaps this should be provided by a non-overloadable operator.
> 
> Short-circuit evaluation is still possible, provided that both sides of the operator return bools.

IMHO, the '&' and '&&' distinction in C isn't clear enough to separate both forms.  You seem to suggest to remove any syntactic difference between the two.  I fear this has a negative effect on readability and maintainability.

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

"Bradeeoh" <bradeeoh@crosswinds.net> writes:

> Because the logistics of bool are different than the logistics of integer.

Are they?

> Integer has (usually) 2^32 individual values, each with their own unique meaning.  The concept of bool means that the value of the variable is either "false" or "true".  With an integer implementation, you change the concept of the bool to "false" or "not false".

Not necessarily.  Sometimes it is useful not to consider representation issues at all and think in terms of more abstract operations on values.

> Represent a bool with individual bits either on or off, and you can have 8 bools take up 1 byte, instead of 8 bytes, easy to implement with D's built in bit type and bit array type.

Yes, of course, but I don't see the relevance of this for 'bool's. This is a representation issue, and I think we were talking about the semantics and the operations available for values of the 'bool' type.

> Just an issue of semantics.  Proper semantics can help you "feel right" :)

Of course, you could make 'bool' an integer type, but please make it distinct from the other integer types (no default implicit conversion, for example).

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Florian Weimer wrote:

> Russ Lewis <russ@deming-os.org> writes:
>
> > > > bool & bool        logical  AND
> > > > bool | bool          logical OR
> > > > !bool                  logical NOT
> > >
> > > What about short-circuit evaluation?  Perhaps this should be provided by a non-overloadable operator.
> >
> > Short-circuit evaluation is still possible, provided that both sides of the operator return bools.
>
> IMHO, the '&' and '&&' distinction in C isn't clear enough to separate both forms.  You seem to suggest to remove any syntactic difference between the two.  I fear this has a negative effect on readability and maintainability.

Sorry, I don't understand what you're getting at.  Can you explain in more detail?