www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The very last thing(s) I'll say about bool is ...

reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
1) Boolean has two values right? 0 and 1, or 0 and !1, or true and false. We
really shouldn't care how they are represented internally. Walter can do
with it what he likes within the compiler. It's certainly syntactically
cleaner to use true and false, regardless of what they represent under the
hood.

2) Boolean should not be assigned a value other than another boolean; from
another variable or from an expression. Straying from this rule should
produce a compile-time error.

3) Boolean implementation should, where it makes a difference, strive for
performance. This relates to both execution time and to memory usage. That
is, if it's more efficient to implement a single boolean variable as a
byte/int/float/class/whatever (under the covers), then let the compiler get
on and do its thing. If, however, memory constraints are the primary factor
then the compiler should at least provide a mechanism for the programmer to
choose such a representation; the boolean[] is potentially an example. Those
who argue that there's never a need (nowadays) to pack data into its
smallest representable space simply have not /yet/ had the need to do so
(it's the "640KB ought to be enough for anyone" argument taken to the 640MB
level).

4) The usage of a boolean value as an arithmetic expression *RValue* has
been around since almost the dawn of programming. It's convenient (and
optimal) in many cases, though some might find the syntax uncomfortable.
It's the kind of thing that comes in handy when bit-twiddling, or trying to
eke out that last bit of whatever. One does not have to use it.

---------------------------

Given that; Walter's choice of a bit to represent boolean values is a fair
one. After all, you only get two values for a bit value, right? Point 1,
totally cool.

D bit variables can *currently* be assigned values other than true or false.
This should be viewed as a bug, and nothing more. Point 2, way bogus.

As it stands, the bit implementation does indeed strive for performance when
used standalone. In fact, it uses a byte. When bit is used as an array, the
compiler switches strategies and packs them into the tightest space it can.
This is fine for many cases, but it /might/ be better if it were programmer
controllable. For example: I may wish to have a fast array of boolean
values. Currently I'd personally implement this as a byte[], but then I've
sacrificed some of the semantic notion of a boolean type. That's my choice,
and one I rather the compiler helped me out with. On the other hand, a
packed bit[] is a godsend for many, and it maintains boolean semantics.
Point 3, mostly cool.

Bit twiddling and optimization are important to systems programmers. D is
intended to cater to that audience. Point 4, cool.

-------------------------------

Additional Commentary:

Please, let's not get hung up on what the underlying implementation should
be; that's missing the point.

Additionally, multiple **API-Level** definitions of what a boolean means
should be avoided at all costs. That is, if you're writing a public API and
you force users to apply your personal version of boolean (as method args,
or whatever), then you're simply fracturing any possible resolution and
confusing the hell out of potential users. In my humble opinion, that's an
entirely selfish route to take. If you're going to be utterly selfless about
sharing your code, why be utterly selfish about a clearly controversial
issue at the same time?

- Kris
Jun 03 2004
next sibling parent reply David L. Davis <SpottedTiger yahoo.com> writes:
In article <c9nqcd$f21$1 digitaldaemon.com>, Kris says...

1) Boolean has two values right? 0 and 1, or 0 and !1, or true and false. We
really shouldn't care how they are represented internally. Walter can do
with it what he likes within the compiler. It's certainly syntactically
cleaner to use true and false, regardless of what they represent under the
hood.

2) Boolean should not be assigned a value other than another boolean; from
another variable or from an expression. Straying from this rule should
produce a compile-time error.

3) Boolean implementation should, where it makes a difference, strive for
performance. This relates to both execution time and to memory usage. That
is, if it's more efficient to implement a single boolean variable as a
byte/int/float/class/whatever (under the covers), then let the compiler get
on and do its thing. If, however, memory constraints are the primary factor
then the compiler should at least provide a mechanism for the programmer to
choose such a representation; the boolean[] is potentially an example. Those
who argue that there's never a need (nowadays) to pack data into its
smallest representable space simply have not /yet/ had the need to do so
(it's the "640KB ought to be enough for anyone" argument taken to the 640MB
level).

4) The usage of a boolean value as an arithmetic expression *RValue* has
been around since almost the dawn of programming. It's convenient (and
optimal) in many cases, though some might find the syntax uncomfortable.
It's the kind of thing that comes in handy when bit-twiddling, or trying to
eke out that last bit of whatever. One does not have to use it.

---------------------------

Given that; Walter's choice of a bit to represent boolean values is a fair
one. After all, you only get two values for a bit value, right? Point 1,
totally cool.

D bit variables can *currently* be assigned values other than true or false.
This should be viewed as a bug, and nothing more. Point 2, way bogus.

As it stands, the bit implementation does indeed strive for performance when
used standalone. In fact, it uses a byte. When bit is used as an array, the
compiler switches strategies and packs them into the tightest space it can.
This is fine for many cases, but it /might/ be better if it were programmer
controllable. For example: I may wish to have a fast array of boolean
values. Currently I'd personally implement this as a byte[], but then I've
sacrificed some of the semantic notion of a boolean type. That's my choice,
and one I rather the compiler helped me out with. On the other hand, a
packed bit[] is a godsend for many, and it maintains boolean semantics.
Point 3, mostly cool.

Bit twiddling and optimization are important to systems programmers. D is
intended to cater to that audience. Point 4, cool.

-------------------------------

Additional Commentary:

Please, let's not get hung up on what the underlying implementation should
be; that's missing the point.

Additionally, multiple **API-Level** definitions of what a boolean means
should be avoided at all costs. That is, if you're writing a public API and
you force users to apply your personal version of boolean (as method args,
or whatever), then you're simply fracturing any possible resolution and
confusing the hell out of potential users. In my humble opinion, that's an
entirely selfish route to take. If you're going to be utterly selfless about
sharing your code, why be utterly selfish about a clearly controversial
issue at the same time?

- Kris


Kris: "Right On The Mark!" :)
Jun 03 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Thu, 3 Jun 2004 20:34:55 +0000 (UTC), David L. Davis 
<SpottedTiger yahoo.com> wrote:

 In article <c9nqcd$f21$1 digitaldaemon.com>, Kris says...

 1) Boolean has two values right? 0 and 1, or 0 and !1, or true and 
 false. We
 really shouldn't care how they are represented internally. Walter can do
 with it what he likes within the compiler. It's certainly syntactically
 cleaner to use true and false, regardless of what they represent under 
 the
 hood.

 2) Boolean should not be assigned a value other than another boolean; 
 from
 another variable or from an expression. Straying from this rule should
 produce a compile-time error.

 3) Boolean implementation should, where it makes a difference, strive 
 for
 performance. This relates to both execution time and to memory usage. 
 That
 is, if it's more efficient to implement a single boolean variable as a
 byte/int/float/class/whatever (under the covers), then let the compiler 
 get
 on and do its thing. If, however, memory constraints are the primary 
 factor
 then the compiler should at least provide a mechanism for the 
 programmer to
 choose such a representation; the boolean[] is potentially an example. 
 Those
 who argue that there's never a need (nowadays) to pack data into its
 smallest representable space simply have not /yet/ had the need to do so
 (it's the "640KB ought to be enough for anyone" argument taken to the 
 640MB
 level).

 4) The usage of a boolean value as an arithmetic expression *RValue* has
 been around since almost the dawn of programming. It's convenient (and
 optimal) in many cases, though some might find the syntax uncomfortable.
 It's the kind of thing that comes in handy when bit-twiddling, or 
 trying to
 eke out that last bit of whatever. One does not have to use it.

 ---------------------------

 Given that; Walter's choice of a bit to represent boolean values is a 
 fair
 one. After all, you only get two values for a bit value, right? Point 1,
 totally cool.

 D bit variables can *currently* be assigned values other than true or 
 false.
 This should be viewed as a bug, and nothing more. Point 2, way bogus.

 As it stands, the bit implementation does indeed strive for performance 
 when
 used standalone. In fact, it uses a byte. When bit is used as an array, 
 the
 compiler switches strategies and packs them into the tightest space it 
 can.
 This is fine for many cases, but it /might/ be better if it were 
 programmer
 controllable. For example: I may wish to have a fast array of boolean
 values. Currently I'd personally implement this as a byte[], but then 
 I've
 sacrificed some of the semantic notion of a boolean type. That's my 
 choice,
 and one I rather the compiler helped me out with. On the other hand, a
 packed bit[] is a godsend for many, and it maintains boolean semantics.
 Point 3, mostly cool.

 Bit twiddling and optimization are important to systems programmers. D 
 is
 intended to cater to that audience. Point 4, cool.

 -------------------------------

 Additional Commentary:

 Please, let's not get hung up on what the underlying implementation 
 should
 be; that's missing the point.

 Additionally, multiple **API-Level** definitions of what a boolean means
 should be avoided at all costs. That is, if you're writing a public API 
 and
 you force users to apply your personal version of boolean (as method 
 args,
 or whatever), then you're simply fracturing any possible resolution and
 confusing the hell out of potential users. In my humble opinion, that's 
 an
 entirely selfish route to take. If you're going to be utterly selfless 
 about
 sharing your code, why be utterly selfish about a clearly controversial
 issue at the same time?

 - Kris


 Kris: "Right On The Mark!" :)


Kris: "Hear! Hear!" :)

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 03 2004
parent reply Rex Couture <Rex_member pathlink.com> writes:
I certainly wouldn't object to a packed (bit or bit array) boolean type, so
maybe more than one boolean type would be OK.  Makes sense to me.  But please,
please keep statements with boolean expressions both simple and type-safe.

I just came into this and I'm not sure I have totally digested all the
conversation, but I have just one other request.  Please, I hope all boolean
names are obvious.  I would be most upset by a boolean type called "red",
"george", or "bit".  :-)

I hope I've merely misunderstood the current and planned status of boolean
types, and that my pleas are superfluous.
Jun 03 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
 I certainly wouldn't object to a packed (bit or bit array) boolean type, so
 maybe more than one boolean type would be OK.  Makes sense to me.  But please,
 please keep statements with boolean expressions both simple and type-safe.


Not sure. My belief is that if the only way to achieve the desired aims of bool
is to disallow arrays of them, and provide another - either library or language
-
construct for arrays, then it's worth it. But this would be a compromise, and
could not be described otherwise.


 I just came into this and I'm not sure I have totally digested all the
 conversation, but I have just one other request.  Please, I hope all boolean
 names are obvious.  I would be most upset by a boolean type called "red",
 "george", or "bit".  :-)


Spot on.


 I hope I've merely misunderstood the current and planned status of boolean
 types, and that my pleas are superfluous.


You haven't. They're not. But they are probably wasted, and you and I should be
saving our keystrokes. :(
Jun 03 2004
prev sibling next sibling parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
"Kris" <someidiot earthlink.dot.dot.dot.net> escribió en el mensaje
news:c9nqcd$f21$1 digitaldaemon.com
| 1) Boolean has two values right? 0 and 1, or 0 and !1, or true and false.
We
| really shouldn't care how they are represented internally. Walter can do
| with it what he likes within the compiler. It's certainly syntactically
| cleaner to use true and false, regardless of what they represent under the
| hood.
|
| ...
|
| - Kris

Just a thought:
I remember that a couple of times ranges were requested. Something like
Pascal/Delphi's:

type my_range = (0..100);

(if I'm not mistaken). Why not finally implement this (with the best syntax
Walter/we can come up with) and define bool as:

range (false..true) bool;

Then bool would finally not accept anything different than false/true, and
each compiler would optimize it any way it wants (I really don't know about
this. Compilers are not something that I know much about) so efficiency
would be ok, I think. Maybe other advantages, and disadvantages for sure
(though I fail to see them).
Again, just a thought. Maybe we could kill two birds with one shot with
this.

-----------------------
Carlos Santander Bernal
Jun 03 2004
parent Rex Couture <Rex_member pathlink.com> writes:
Carlos wrote:

range (false..true) bool;


I'm not sure I'm qualified to judge about implementation, but it looks like a
great idea and passes the user test with me.


I'm not trying to request another feature, but D users might also like something
like this:

boolean goodChoice;
int consequence[goodChoice];
or
int consequence[boolean];

This is translated Pascal, but you get the idea.
Jun 03 2004
prev sibling next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
news:c9nqcd$f21$1 digitaldaemon.com...

 1) Boolean has two values right? 0 and 1, or 0 and !1, or true and false. We
 really shouldn't care how they are represented internally. Walter can do
 with it what he likes within the compiler. It's certainly syntactically
 cleaner to use true and false, regardless of what they represent under the
 hood.


Well, this is a newsgroup that, in part, is about how we will implement the new
language D. If you think we should not be looking into how things are
implemented, you're in the wrong NG. Or maybe it's time for yet another group
D.users?


 2) Boolean should not be assigned a value other than another boolean; from
 another variable or from an expression. Straying from this rule should
 produce a compile-time error.


Absolutely correct. As I've said several times, this is the more important of
the
two issues - size being the other - but it's also the one that I think we're
least likely to shake Walter on.


 3) Boolean implementation should, where it makes a difference, strive for
 performance. This relates to both execution time and to memory usage. That
 is, if it's more efficient to implement a single boolean variable as a
 byte/int/float/class/whatever (under the covers), then let the compiler get
 on and do its thing. If, however, memory constraints are the primary factor
 then the compiler should at least provide a mechanism for the programmer to
 choose such a representation; the boolean[] is potentially an example. Those
 who argue that there's never a need (nowadays) to pack data into its
 smallest representable space simply have not /yet/ had the need to do so
 (it's the "640KB ought to be enough for anyone" argument taken to the 640MB
 level).


I said in this about two months ago. Best of luck getting any more interest than
I got. ;/


 4) The usage of a boolean value as an arithmetic expression *RValue* has
 been around since almost the dawn of programming. It's convenient (and
 optimal) in many cases, though some might find the syntax uncomfortable.
 It's the kind of thing that comes in handy when bit-twiddling, or trying to
 eke out that last bit of whatever. One does not have to use it.


If I understand you correctly, you're arguing that we should be able to use a
boolean variable in an integral expression. If that's the case, you are
contradicting point 2)

Please confirm/deny.



 ---------------------------

 Given that; Walter's choice of a bit to represent boolean values is a fair
 one. After all, you only get two values for a bit value, right? Point 1,
 totally cool.


Arguable, but I'll go with you. :-)


 D bit variables can *currently* be assigned values other than true or false.
 This should be viewed as a bug, and nothing more. Point 2, way bogus.


Correct. Big bogus.


 As it stands, the bit implementation does indeed strive for performance when
 used standalone. In fact, it uses a byte. When bit is used as an array, the
 compiler switches strategies and packs them into the tightest space it can.
 This is fine for many cases, but it /might/ be better if it were programmer
 controllable. For example: I may wish to have a fast array of boolean
 values. Currently I'd personally implement this as a byte[], but then I've
 sacrificed some of the semantic notion of a boolean type. That's my choice,
 and one I rather the compiler helped me out with. On the other hand, a
 packed bit[] is a godsend for many, and it maintains boolean semantics.
 Point 3, mostly cool.


How do you like this for efficient:

  bool b = null !== p;

? The compiler has to do something like (p != 0xfffffff) ? 1 : 0.

I don't call that optimal. If bool is the size of the architecture, say 32-bits,
then the compiler can translate every boolean expression into that size, and
every test can be a single one, i.e. without the need to translate into 1 or 0.
Things are either 0 (or 0x00000000) or !0 (0x00000001 => 0xFFFFFFFF). It doesn't
matter, and it's as fast as is possible to be.


 Bit twiddling and optimization are important to systems programmers. D is
 intended to cater to that audience. Point 4, cool.


They are. But if bit and bool are separate things then Point 4 is cool. As it
stands 4) violates 2), so this reasoning is flawed.


 -------------------------------

 Additional Commentary:

 Please, let's not get hung up on what the underlying implementation should
 be; that's missing the point.


Again, this is a NG for the design and implementation of D. What, then, is
inappropriate about our discussing this, or any other, implementation issue?


 Additionally, multiple **API-Level** definitions of what a boolean means
 should be avoided at all costs. That is, if you're writing a public API and
 you force users to apply your personal version of boolean (as method args,
 or whatever), then you're simply fracturing any possible resolution and
 confusing the hell out of potential users. In my humble opinion, that's an
 entirely selfish route to take. If you're going to be utterly selfless about
 sharing your code, why be utterly selfish about a clearly controversial
 issue at the same time?


Well, I kind of agree, and I kind of don't. I see the current bool definition as
flawed, and potentially buggy. While it's certainly easier to go along with
Walter's vision of bool, you can't exactly say that doing would be an
unequivocal
kindness to my users. If I supply something that's easier to use, but more prone
to misuse, is that really being selfless? If I require them to add a couple of
casts here and there in order to do something bad, is that selfish?

Yet again, and for the last 2 years, I sigh at the apparent preference for ease
of coding over maintenance and robustness concerns. Pretty much every master of
this industry - Brooks, Glass, Meyers, Sutter, Kernighan, Fowler, Hunt & Thomas,
Raymond, etc. etc. etc. etc. ad infinitum - stresses time and again that
maintenance/debugging/refactoring costs dwarf the initial coding cost. So
leaving
a language, or its libraries, open to more errors than necessary for the sake of
some dinky little trick / saving a line of code could be said to be ...
<searching for as inoffensive word as possible> ... wrong.

Or maybe it's just me, and I shouldn't want D to address the abject, and
multi-billion-dollar wasteful, failures of other languages, and end up being a
roaring success. Let's just have it as a partial, buggy, semi-cool thing for
hobbyists and people who want to spend their time in debuggers. :(
Jun 03 2004
next sibling parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
Hey Matthew,

The title says it all, but since you asked for clarification:

"Matthew"  wrote

 If I understand you correctly, you're arguing that we should be able to


use a

 boolean variable in an integral expression. If that's the case, you are
 contradicting point 2)

 Please confirm/deny.


My statement tried to be clear about this usage as an arithmetic RValue,
rather than an LValue. An LValue is the target of an assignment, whereas an
RValue is typically anything on the right-hand side of the '='. This doesn't
contradict point 2, which is talking about the bool strictly as an LValue.

BTW I'm not as you say, arguing point 4 per se. I'm just pointing out its
history and usage. I am personally comfortable with the boolean RValue style
syntax, but wouldn't cry out if it were not supported. In other words, this
point is of relatively low value. I hope this clarifies suitably?



 Well, this is a newsgroup that, in part, is about how we will implement


the new

 language D. If you think we should not be looking into how things are
 implemented, you're in the wrong NG. Or maybe it's time for yet another


group

 D.users?


Perhaps you are in the wrong newsgroup, good Dr ... I would put it to you
that the majority of users on the NG are exactly that. Users. I mean,
discussing the language usage, features, limitations, restrictions, or new
ideas are often quite a world apart from the actual underlying compiler
implementation issues. This, you already know. Part of the problem in
combining the two is that it causes unnecessary worry and thrashing within
the overall group.

Might you consider another group called D.internals, or
D.implementation.all.in.mud.wrestling, instead? Yes ~ you've already stated
how thick your skin is, so permit me some latitude here please <g>

Regards;
Jun 03 2004
next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
news:c9oh61$1gat$1 digitaldaemon.com...

 Hey Matthew,

 The title says it all, but since you asked for clarification:

 "Matthew"  wrote

 If I understand you correctly, you're arguing that we should be able to


 use a

 boolean variable in an integral expression. If that's the case, you are
 contradicting point 2)

 Please confirm/deny.


 My statement tried to be clear about this usage as an arithmetic RValue,
 rather than an LValue. An LValue is the target of an assignment, whereas an
 RValue is typically anything on the right-hand side of the '='. This doesn't
 contradict point 2, which is talking about the bool strictly as an LValue.


It's (mis-)use as an rvalue is, IMO, far more frequent than that of lvalue. I
don't see that we buy much in prescribing one, and proscribing the other. And
the
downside is more confusion.


 BTW I'm not as you say, arguing point 4 per se. I'm just pointing out its
 history and usage. I am personally comfortable with the boolean RValue style
 syntax, but wouldn't cry out if it were not supported. In other words, this
 point is of relatively low value. I hope this clarifies suitably?


Sure.


 Well, this is a newsgroup that, in part, is about how we will implement


 the new

 language D. If you think we should not be looking into how things are
 implemented, you're in the wrong NG. Or maybe it's time for yet another


 group

 D.users?


 Perhaps you are in the wrong newsgroup, good Dr ... I would put it to you
 that the majority of users on the NG are exactly that.


Majority is not all, and in the absence of another forum, such issues must be
dealt with here.

And hey! There's nothing good about me. I've been trying to heal myself for a
long time ...


 Users. I mean,
 discussing the language usage, features, limitations, restrictions, or new
 ideas are often quite a world apart from the actual underlying compiler
 implementation issues. This, you already know. Part of the problem in
 combining the two is that it causes unnecessary worry and thrashing within
 the overall group.


A very good point. New NG, big-W?


 Might you consider another group called D.internals, or
 D.implementation.all.in.mud.wrestling, instead? Yes ~ you've already stated
 how thick your skin is, so permit me some latitude here please <g>


He he. I think it could be D.implementation.endless.pontification, or
D.implementation.ego.joust.

Professor Frederick von Crute

Author: "Imperfect C++", Addison-Wesley, 2004
    (http://www.imperfectcplusplus.com)
Contributing editor, C/C++ Users Journal
    (http://www.synesis.com.au/articles.html#columns)
Director, Synesis Software
    (www.synesis.com.au)
STLSoft moderator
    (http://www.stlsoft.org)

-----------------------------------------------------
Jun 03 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
 Perhaps you are in the wrong newsgroup, good Dr ... I would put it to you
 that the majority of users on the NG are exactly that. Users. I mean,
 discussing the language usage, features, limitations, restrictions, or new
 ideas are often quite a world apart from the actual underlying compiler
 implementation issues. This, you already know. Part of the problem in
 combining the two is that it causes unnecessary worry and thrashing within
 the overall group.

 Might you consider another group called D.internals, or
 D.implementation.all.in.mud.wrestling, instead? Yes ~ you've already stated
 how thick your skin is, so permit me some latitude here please <g>


I'm just thinking. Can you imagine when we all meet up at the inaugural
ISO/ANSI-D meeting. How many of you will try and take a pop at my <translation
actual="ugly mug">august countenance</translation>?

<G>
Jun 03 2004
prev sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Fri, 4 Jun 2004 10:16:49 +1000, Matthew <matthew.hat stlsoft.dot.org> 
wrote:

 "Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
 news:c9nqcd$f21$1 digitaldaemon.com...

 1) Boolean has two values right? 0 and 1, or 0 and !1, or true and 
 false. We
 really shouldn't care how they are represented internally. Walter can do
 with it what he likes within the compiler. It's certainly syntactically
 cleaner to use true and false, regardless of what they represent under 
 the
 hood.


 Well, this is a newsgroup that, in part, is about how we will implement 
 the new
 language D. If you think we should not be looking into how things are
 implemented, you're in the wrong NG. Or maybe it's time for yet another 
 group
 D.users?


What Kris was trying to say (correct me if I am wrong) was that we should 
concentrate on how bool looks to the programmer not how it is done. Or 
rather that in this thread that is what he wants to do, start another 
thread on the implementation but just concentrate on looks here.


 2) Boolean should not be assigned a value other than another boolean; 
 from
 another variable or from an expression. Straying from this rule should
 produce a compile-time error.


 Absolutely correct. As I've said several times, this is the more 
 important of the
 two issues - size being the other - but it's also the one that I think 
 we're
 least likely to shake Walter on.


 3) Boolean implementation should, where it makes a difference, strive 
 for
 performance. This relates to both execution time and to memory usage. 
 That
 is, if it's more efficient to implement a single boolean variable as a
 byte/int/float/class/whatever (under the covers), then let the compiler 
 get
 on and do its thing. If, however, memory constraints are the primary 
 factor
 then the compiler should at least provide a mechanism for the 
 programmer to
 choose such a representation; the boolean[] is potentially an example. 
 Those
 who argue that there's never a need (nowadays) to pack data into its
 smallest representable space simply have not /yet/ had the need to do so
 (it's the "640KB ought to be enough for anyone" argument taken to the 
 640MB
 level).


 I said in this about two months ago. Best of luck getting any more 
 interest than
 I got. ;/


This could be the difference between a 'bool' and a 'bit'. eg 'bit' is 
packed and 'bool' is not. It would of course require the creation of a 
'bool' type and the removal of the alias of bit.


 4) The usage of a boolean value as an arithmetic expression *RValue* has
 been around since almost the dawn of programming. It's convenient (and
 optimal) in many cases, though some might find the syntax uncomfortable.
 It's the kind of thing that comes in handy when bit-twiddling, or 
 trying to
 eke out that last bit of whatever. One does not have to use it.


 If I understand you correctly, you're arguing that we should be able to 
 use a
 boolean variable in an integral expression. If that's the case, you are
 contradicting point 2)

 Please confirm/deny.



to assign to a bool something that is not bool, in other words if a bool 
is the lvalue you must have a bool as the rvalue.

Here he's saying that implicit conversion from bool to other integral 
types is often used and should stay.

(pls correct me if I am wrong Kris)


 ---------------------------

 Given that; Walter's choice of a bit to represent boolean values is a 
 fair
 one. After all, you only get two values for a bit value, right? Point 1,
 totally cool.


 Arguable, but I'll go with you. :-)


 D bit variables can *currently* be assigned values other than true or 
 false.
 This should be viewed as a bug, and nothing more. Point 2, way bogus.


 Correct. Big bogus.


 As it stands, the bit implementation does indeed strive for performance 
 when
 used standalone. In fact, it uses a byte. When bit is used as an array, 
 the
 compiler switches strategies and packs them into the tightest space it 
 can.
 This is fine for many cases, but it /might/ be better if it were 
 programmer
 controllable. For example: I may wish to have a fast array of boolean
 values. Currently I'd personally implement this as a byte[], but then 
 I've
 sacrificed some of the semantic notion of a boolean type. That's my 
 choice,
 and one I rather the compiler helped me out with. On the other hand, a
 packed bit[] is a godsend for many, and it maintains boolean semantics.
 Point 3, mostly cool.


 How do you like this for efficient:

   bool b = null !== p;

 ? The compiler has to do something like (p != 0xfffffff) ? 1 : 0.

 I don't call that optimal. If bool is the size of the architecture, say 
 32-bits,
 then the compiler can translate every boolean expression into that size, 
 and
 every test can be a single one, i.e. without the need to translate into 
 1 or 0.
 Things are either 0 (or 0x00000000) or !0 (0x00000001 => 0xFFFFFFFF). It 
 doesn't
 matter, and it's as fast as is possible to be.


I can't comment here. This is implementation I think we should start by 
deciding how it should look and act before we decide how it is implemented.


 Bit twiddling and optimization are important to systems programmers. D 
 is
 intended to cater to that audience. Point 4, cool.


 They are. But if bit and bool are separate things then Point 4 is cool. 
 As it
 stands 4) violates 2), so this reasoning is flawed.


I don't think 4) violates 2) (see my reasoning above)


 -------------------------------

 Additional Commentary:

 Please, let's not get hung up on what the underlying implementation 
 should
 be; that's missing the point.


 Again, this is a NG for the design and implementation of D. What, then, 
 is
 inappropriate about our discussing this, or any other, implementation 
 issue?


Sure, but do it in another thread, i.e. one thread for how bool looks and 
acts and one for the implementation. Lets get one out of the way before 
moving on to the other.


 Additionally, multiple **API-Level** definitions of what a boolean means
 should be avoided at all costs. That is, if you're writing a public API 
 and
 you force users to apply your personal version of boolean (as method 
 args,
 or whatever), then you're simply fracturing any possible resolution and
 confusing the hell out of potential users. In my humble opinion, that's 
 an
 entirely selfish route to take. If you're going to be utterly selfless 
 about
 sharing your code, why be utterly selfish about a clearly controversial
 issue at the same time?


 Well, I kind of agree, and I kind of don't. I see the current bool 
 definition as
 flawed, and potentially buggy.


I am having a hard time thinking of a possible bug someone might write. 
Lets assume 2) above is changed, can you give me an example of where using 
a bool as an rvalue as in Walters previous examples causes a bug not 
caught by the compiler.


 While it's certainly easier to go along with
 Walter's vision of bool, you can't exactly say that doing would be an 
 unequivocal
 kindness to my users. If I supply something that's easier to use, but 
 more prone
 to misuse, is that really being selfless? If I require them to add a 
 couple of
 casts here and there in order to do something bad, is that selfish?


http://www.datanation.com/fallacies/ap.htm
(please don't take offence)


 Yet again, and for the last 2 years, I sigh at the apparent preference 
 for ease
 of coding over maintenance and robustness concerns. Pretty much every 
 master of
 this industry - Brooks, Glass, Meyers, Sutter, Kernighan, Fowler, Hunt & 
 Thomas,
 Raymond, etc. etc. etc. etc. ad infinitum - stresses time and again that
 maintenance/debugging/refactoring costs dwarf the initial coding cost. 
 So leaving
 a language, or its libraries, open to more errors than necessary for the 
 sake of
 some dinky little trick / saving a line of code could be said to be ...
 <searching for as inoffensive word as possible> ... wrong.


Being a C programmer I am probably biased, I have seen Walters examples, I 
think they are clearer than the others proposed. If it is well known that 
bool is implicitly castable to int and has a value of 0 or 1 then I cannot 
see the problem.

It doesn't stop you from coding the casts to make your code 'clearer' 
regardless of whether the compiler requires it.


 Or maybe it's just me, and I shouldn't want D to address the abject, and
 multi-billion-dollar wasteful, failures of other languages, and end up 
 being a
 roaring success. Let's just have it as a partial, buggy, semi-cool thing 
 for
 hobbyists and people who want to spend their time in debuggers. :(


http://www.datanation.com/fallacies/conseq.htm
(please don't take offence)

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 03 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 Well, I kind of agree, and I kind of don't. I see the current bool
 definition as
 flawed, and potentially buggy.


 I am having a hard time thinking of a possible bug someone might write.
 Lets assume 2) above is changed, can you give me an example of where using
 a bool as an rvalue as in Walters previous examples causes a bug not
 caught by the compiler.


Easy:

Vector2D!(int) makeVector2D(int a, int c)
{
   void * pv = ....
    bool b = null !== pv;

  return new Vector2D!(int)(a, b); // Big f*ing ouch!!
}


 While it's certainly easier to go along with
 Walter's vision of bool, you can't exactly say that doing would be an
 unequivocal
 kindness to my users. If I supply something that's easier to use, but
 more prone
 to misuse, is that really being selfless? If I require them to add a
 couple of
 casts here and there in order to do something bad, is that selfish?


 http://www.datanation.com/fallacies/ap.htm
 (please don't take offence)


None taken. (Remember, I'm English: taking the piss out of oneself is the
national sport. <g>) I'm not sure it's perfectly apposite, but I think it's
funny
enough to be worth a try. argumentum ad misercordiam - cool!


 Yet again, and for the last 2 years, I sigh at the apparent preference
 for ease
 of coding over maintenance and robustness concerns. Pretty much every
 master of
 this industry - Brooks, Glass, Meyers, Sutter, Kernighan, Fowler, Hunt &
 Thomas,
 Raymond, etc. etc. etc. etc. ad infinitum - stresses time and again that
 maintenance/debugging/refactoring costs dwarf the initial coding cost.
 So leaving
 a language, or its libraries, open to more errors than necessary for the
 sake of
 some dinky little trick / saving a line of code could be said to be ...
 <searching for as inoffensive word as possible> ... wrong.


 Being a C programmer I am probably biased, I have seen Walters examples, I
 think they are clearer than the others proposed. If it is well known that
 bool is implicitly castable to int and has a value of 0 or 1 then I cannot
 see the problem.


See the example above. There are - in principle _and_ in practice - myriad
others.


 It doesn't stop you from coding the casts to make your code 'clearer'
 regardless of whether the compiler requires it.


I'm sorry, but this is just rot. If there is a semantic type conversion
involved - and let's be clear: converting from a bool (truth) to an int
(numeric)
*is* a semantic type conversion - then the code is not rendered less clear by
requiring a cast to inform the reader.

Once again, this peurile bias for ease of coding over than ease of maintenance
flashes it's cheeky little grin. Casts are ugly, and make your code look messy.
Yes, indeed; that's precisely the point. Bjarne Stroustrup indicates that he
chose the C++ cast names for that very reason. When you look at code with casts
in it, warnings bells *should* ring in your head. With syntax highlighting
(whether for C++'s "static_cast" or D's "cast"), this is a significant boon to
code maintainers.

You've offered up your C heritage/experience, so I am compelled to ascribe what
I
see as naivety to that. C programmers are used to all casts being equal, and to
casts being a normal part of life. They are not thus viewed in other languages,
and for good reason.


 Or maybe it's just me, and I shouldn't want D to address the abject, and
 multi-billion-dollar wasteful, failures of other languages, and end up
 being a
 roaring success. Let's just have it as a partial, buggy, semi-cool thing
 for
 hobbyists and people who want to spend their time in debuggers. :(


 http://www.datanation.com/fallacies/conseq.htm
 (please don't take offence)


You're off base here, I'm afraid. But I acknowledge your willingness to try and
get two laughs out of the same joke.

Each of the established languages has advantages over the others. For D to score
market share, it needs to have new features that others do not have, and at the
same time not have sufficient level of existing/new warts that it renders these
advantages moot. Given that D does not have a huge corporate backer, it's going
to have to try harder than the others. Can anyone really see themselves selling
a
new, unsponsored, language to a client/boss on the basis of mixins and similarly
groovy but inaccessible concepts when it hasn't even got the fundamentals right?
Jun 03 2004
parent Regan Heath <regan netwin.co.nz> writes:
On Fri, 4 Jun 2004 13:33:36 +1000, Matthew <matthew.hat stlsoft.dot.org> 
wrote:

 Well, I kind of agree, and I kind of don't. I see the current bool
 definition as
 flawed, and potentially buggy.


 I am having a hard time thinking of a possible bug someone might write.
 Lets assume 2) above is changed, can you give me an example of where 
 using
 a bool as an rvalue as in Walters previous examples causes a bug not
 caught by the compiler.


 Easy:

 Vector2D!(int) makeVector2D(int a, int c)
 {
    void * pv = ....
     bool b = null !== pv;

   return new Vector2D!(int)(a, b); // Big f*ing ouch!!
 }


Thanks.

I don't think this example would ever occur in a real world application.

I mean.. C doesn't have bool, so I cannot say 'I have or have not ever 
come accross a bug like this'. BUT. I can say I have *never* accidently 
passed an int I was using as a bool to a function that required an int.

That is why I am having trouble coming up with a bug, that removing 
implicit casting from bool to int would have prevented.


 While it's certainly easier to go along with
 Walter's vision of bool, you can't exactly say that doing would be an
 unequivocal
 kindness to my users. If I supply something that's easier to use, but
 more prone
 to misuse, is that really being selfless? If I require them to add a
 couple of
 casts here and there in order to do something bad, is that selfish?


 http://www.datanation.com/fallacies/ap.htm
 (please don't take offence)


 None taken. (Remember, I'm English: taking the piss out of oneself is the
 national sport. <g>) I'm not sure it's perfectly apposite, but I think 
 it's funny
 enough to be worth a try. argumentum ad misercordiam - cool!


 Yet again, and for the last 2 years, I sigh at the apparent preference
 for ease
 of coding over maintenance and robustness concerns. Pretty much every
 master of
 this industry - Brooks, Glass, Meyers, Sutter, Kernighan, Fowler, 


 Hunt &

 Thomas,
 Raymond, etc. etc. etc. etc. ad infinitum - stresses time and again 


 that

 maintenance/debugging/refactoring costs dwarf the initial coding cost.
 So leaving
 a language, or its libraries, open to more errors than necessary for 


 the

 sake of
 some dinky little trick / saving a line of code could be said to be 


 ...

 <searching for as inoffensive word as possible> ... wrong.


 Being a C programmer I am probably biased, I have seen Walters 
 examples, I
 think they are clearer than the others proposed. If it is well known 
 that
 bool is implicitly castable to int and has a value of 0 or 1 then I 
 cannot
 see the problem.


 See the example above. There are - in principle _and_ in practice - 
 myriad
 others.


I just want 1 real world example, has anyone got one, surely someone has 
an actual bug they found and fixed that involved implicit casting from 
bool to int?


 It doesn't stop you from coding the casts to make your code 'clearer'
 regardless of whether the compiler requires it.


 I'm sorry, but this is just rot.


Why? You can can't you. And it will document your code for others to see. 
Where's the problem?


 If there is a semantic type conversion
 involved - and let's be clear: converting from a bool (truth) to an int 
 (numeric)
 *is* a semantic type conversion


No-one is arguing this point.


 - then the code is not rendered less clear by
 requiring a cast to inform the reader.


Never said it was.


 Once again, this peurile bias for ease of coding over than ease of 
 maintenance
 flashes it's cheeky little grin. Casts are ugly, and make your code look 
 messy.


Yep. They make code harder to read next time you come back to it.


 Yes, indeed; that's precisely the point. Bjarne Stroustrup indicates 
 that he
 chose the C++ cast names for that very reason. When you look at code 
 with casts
 in it, warnings bells *should* ring in your head. With syntax 
 highlighting
 (whether for C++'s "static_cast" or D's "cast"), this is a significant 
 boon to
 code maintainers.


I dislike them, they're ugly. :)


 You've offered up your C heritage/experience, so I am compelled to 
 ascribe what I
 see as naivety to that. C programmers are used to all casts being equal, 
 and to
 casts being a normal part of life. They are not thus viewed in other 
 languages,
 and for good reason.


There is nothing wrong with casts... I thought you were arguing implicit 
casting is bad, are all casts bad now?


 Or maybe it's just me, and I shouldn't want D to address the abject, 


 and

 multi-billion-dollar wasteful, failures of other languages, and end up
 being a
 roaring success. Let's just have it as a partial, buggy, semi-cool 


 thing

 for
 hobbyists and people who want to spend their time in debuggers. :(


 http://www.datanation.com/fallacies/conseq.htm
 (please don't take offence)


 You're off base here, I'm afraid.


How? You were arguing *for* something by detailing some supposed 
consequences and *implying* they would occur if you are ignored.


 But I acknowledge your willingness to try and
 get two laughs out of the same joke.

 Each of the established languages has advantages over the others. For D 
 to score
 market share, it needs to have new features that others do not have, and 
 at the
 same time not have sufficient level of existing/new warts that it 
 renders these
 advantages moot. Given that D does not have a huge corporate backer, 
 it's going
 to have to try harder than the others. Can anyone really see themselves 
 selling a
 new, unsponsored, language to a client/boss on the basis of mixins and 
 similarly
 groovy but inaccessible concepts when it hasn't even got the 
 fundamentals right?


So now you're saying D will never survive if it implicitly casts bool to 
int?
C++ does. it's doing pretty well.

D already has advantages over C++ and has not added any flaws (that do not 
exist in C++ already)

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 03 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
Spawning a whole new thread on it <g>.
Jun 03 2004
parent reply "Phill" <phill pacific.net.au> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:c9ok5p$1k7i$2 digitaldaemon.com...

 Spawning a whole new thread on it <g>.


Maybe the new NG should be called
"D Bool"

I dont care what anyone says, I say that bool
should return one of three values:

"true", "false" and "Im not sure"

Phill.
Jun 06 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <c9ur8o$1l21$1 digitaldaemon.com>, Phill says...


I dont care what anyone says, I say that bool
should return one of three values:

"true", "false" and "Im not sure"


The function Int.isProbablyPrime() does just that, although actually I just
returned an int. I keep wondering if I should have invented a three-valued enum.

Arcane Jill
Jun 06 2004
parent "KTC" <me here.com> writes:
"Arcane Jill" wrote...

 In article <c9ur8o$1l21$1 digitaldaemon.com>, Phill says...


I dont care what anyone says, I say that bool
should return one of three values:

"true", "false" and "Im not sure"


 The function Int.isProbablyPrime() does just that, although actually I
 just returned an int. I keep wondering if I should have invented a
 three-valued enum.

 Arcane Jill


Have an Int.isPrime() that implements AKS maybe ? That way, you wouldn't
need to invent a three-valued enum :-)

KTC

-- 
Experience is a good school but the fees are high.
    - Heinrich Heine
Jun 06 2004
prev sibling parent "Martin M. Pedersen" <martin moeller-pedersen.dk> writes:
How about defining bool as a float being a probability in range [0.0 ..1.0]
:-)

"Phill" <phill pacific.net.au> wrote in message
news:c9ur8o$1l21$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message
 news:c9ok5p$1k7i$2 digitaldaemon.com...

 Spawning a whole new thread on it <g>.


 Maybe the new NG should be called
 "D Bool"

 I dont care what anyone says, I say that bool
 should return one of three values:

 "true", "false" and "Im not sure"

 Phill.
Jun 06 2004