One more time...

C has it wrong in several ways.  I have programmed C for over 20 years.

Bools are bits, but bits are not only boolean.  Arithmetics, characters, and addresses are not boolean.  Comparisons produce a boolean value.

Bits are 1:0, true:false, yes:no, flags, switches, checkmarks, ...

Bits are not useful as numbers for arithmetic operations.  Their arrays should not automatically become so.

I have no problem with numbers and characters being subject to logic operations, but bits are not directly useful for arithmetic operations.

Perhaps shifting of bit arrays could be useful when used as a rotating mask or some such.  We have that with slicing of arrays as well as selection out of contiguous groups of flags or switches.

Comparative operations result in a true:false value entirely interpretable as a bit.  They should be valid in the right hand side of an assignment or initialization for bits, but not numerics.

Casting of a bit array as a numeric to be able to compare it to a number does make some sense and could be implicit.  Assembling a number in a bit array and then casting it is less useful, but maybe.  We do have logic operations directly on numerics and characters to do anything that may be needed there.  Explicit casting of a numeric or character as a bit array is probably necessary for analytic purposes, but should never be implicit.  Explicit casting of a bit array as a character or numeric should probably be handled by unions.


I propose the following:

1. All usage of numerics, characters, and addresses as boolean values should be rejected by the compiler.  The need for === as well as == should blow away use of addresses, and the evaluation of true as "anything not composed fully of zero bits" is just nasty.

2. All usage of bits and bit arrays for numeric operations (except comparison as allowed below) should be rejected by the compiler.  Logic operations suffice and are more descriptive and are well-defined.

3. Comparisons between numbers and characters with bits and bit arrays are well-defined and should be supported with implicit casting.  High order 0 bits should be assumed as necesssary for compatible unit sizes.

4. No other implicit casts should be injected back and forth.

5. Shift operations on bit arrays are unnecessary and should not be supported except by slicing and concatenating.  The compiler should be able to optimize down to minimal operations when appropriate.

6. There should be no need for compiler requirements of either packed or not-packed bit arrays or arrays of bit arrays.  Structs and arrays of structs can fully describe anything there (see below).  Implementation should be left to the compiler vendor for this.  It's tied too closely to optimization.

7. Structs with successive bits and bit arrays should be packable down to minimum size|width.  Offsetting can be accomplished explicitly with dummy bits. Bytes, shorts, ints, chars, etc should not intrude - they have their own boundary considerations which should still be met with minimum of modulo-8 bit addresses.  It would be nice if placeholder bits and bytes did not require names, but that's just syntactic sugar.

8. Unions which include bits and|or bit arrays can fill in the rest, and
probably should be used rather than casting bit arrays elsewhere anyway..
It therefore would be possible to disallow even explicit casting back and forth
between logic and other representations but I'm not proposing this.

9. Add on:off as keywords identical to true:false.  Their valuation as 1:0 is consistent with most other languages and programmatic use (though often allowed as any:0 instead), so keep that.

10. Fix that C/C++ code.  It won't hurt to check the logic anyway - it may not be exactly the same when pointers and references are considered properly. While(1) {} and for(;;) {} both can easily be changed to while(true) {} and be more safely readable.  [ We have "foreach" now, we could add "forever".  I like the "forever break;" statement as a no-op. ] We have already blown away "for(...;...;...) ;" for good reasons, so there's some precedent for changes which require actually looking at C code (if you can find any without preprocessor use) before D compiling it.

11. Let's please take at least this step toward making type safety possible.


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

Another thread should take up the ignorance of C about arithmetic and logical overflows and underflows and propose something there. (Not necessarily unaware, but no provision for access and handling.)  The hardware knows, why can't the programmer?.  ints uints, oints, ouints?  smart operations?  an _ or an @ standard variable?  this gets tangled with the problems of actual vs. potential lossy casts as well.  And don't tell me to use assembler when I want this... Do not reply to this in this thread, please.

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





6.

larrycowan wrote:

> One more time...

New thread, old discussion...

> I propose the following:
> 
> 1. All usage of numerics, characters, and addresses as boolean values should be
> rejected by the compiler.  The need for === as well as == should blow away use
> of addresses, and the evaluation of true as "anything not composed fully of zero
> bits" is just nasty.

Note: This D suggestion has been rejected by Walter.

D currently follows the same "nasty" rules as C/C++.
Type safety as in C# is more likely first in "D 2.0"

> 9. Add on:off as keywords identical to true:false.  Their valuation as 1:0 is
> consistent with most other languages and programmatic use (though often allowed
> as any:0 instead), so keep that.

Hear, hear!

This is more or less the same thing as I suggested earlier,
keywords to the equivalent effect of the following #defines:

const bit on = 1;
const bit off = 0;

Preferrably, a "bool" type (like C++) can be added to D?
Barring that, the same kludge as in C99 would have to do:

module std.stdbool;
alias bit bool;
const bool true = 1;
const bool false = 0;

> 11. Let's please take at least this step toward making type safety possible.

The first step would be *having* two different types for bits and bools?

--anders

In article <ckm861$2nng$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>larrycowan wrote:
>
>> One more time...
>
>New thread, old discussion...
>
>> I propose the following:
>> 
>> 1. All usage of numerics, characters, and addresses as boolean values should be rejected by the compiler.  The need for === as well as == should blow away use of addresses, and the evaluation of true as "anything not composed fully of zero bits" is just nasty.
>
>Note: This D suggestion has been rejected by Walter.

I know that.  Not just once, many times.  Still, too many peole have the opinion that this should change.

>
>D currently follows the same "nasty" rules as C/C++.

So?  Does that make it good?

>Type safety as in C# is more likely first in "D 2.0"

No, not "like in C#", type safety is not a MS concept!

..

>> 11. Let's please take at least this step toward making type safety possible.
>
>The first step would be *having* two different types for bits and bools?
>
>--anders

What justification is there for a bit type that is not only the boolean?

Are you sure you don't want signed and unsigned bits? You could use the signed bit in a union with the high bit of an unsigned int to pretend it was signed and invent your own arithmetic.  And an unsigned bit similarly to see if you were vulnerable to overflows...

No - we don't need bits for arithmetic! or to build utf-13 character sets with!

My proposal does not give us type safety (though it would greatly help), but it surely does make it less disruptive to provide it later.

larry cowan wrote:

>>D currently follows the same "nasty" rules as C/C++.
> 
> So?  Does that make it good?

Well, perhaps not. But it does make it familiar to many ?

Just like you, I had hoped for D to improve upon this -
like it improves on other things that are "old" in C.

>>Type safety as in C# is more likely first in "D 2.0"
> 
> No, not "like in C#", type safety is not a MS concept!

Isn't it? Right after they invented the Internet ? :-)

Seriously, I meant "implemented as in C#". I used to say
"as in Java", but they chose the "boolean" keyword instead ?

In C#, bool is just an alias for System.Boolean but who cares.
It's not convertable to the other types, like int and such.


I wrote a long essay about the now somewhat boring subject in:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/11757

--anders


BTW; I am using Mono for my C# needs. Not that they are many.

>larry cowan wrote: No, not "like in C#", type safety is not a MS concept!
>
>Anders wrote: Isn't it? Right after they invented the Internet ? :-)

No, I think it was Al Gore who raised his hand first and took the credit for inventing the Internet...soon after he learned how to spell "potato." :)

Sorry, I just couldn't help myself.

David L.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"

In article <ckmauc$2qpk$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>larry cowan wrote:
>
>>>D currently follows the same "nasty" rules as C/C++.
>> 
>> So?  Does that make it good?
>
>Well, perhaps not. But it does make it familiar to many ?

So is the preprocessor.
>
>Just like you, I had hoped for D to improve upon this - like it improves on other things that are "old" in C.
>
>>>Type safety as in C# is more likely first in "D 2.0"
>> 
>> No, not "like in C#", type safety is not a MS concept!
>
>Isn't it? Right after they invented the Internet ? :-)

No, I invented it.  I just couldn't spare the time to implement it.

>
>Seriously, I meant "implemented as in C#". I used to say "as in Java", but they chose the "boolean" keyword instead ?
>
>In C#, bool is just an alias for System.Boolean but who cares. It's not convertable to the other types, like int and such.

A boolean class would provide whatever we wanted however we wanted it, but not as efficiently most likely.  But that doesn't kill the bad C'isms we are carrying forward in regard to expression defaults based on "any nozero is true" concepts.  I don't even want "bit[] xa; ...; if (xa) {}" to be valid as "if any bit in xa is non-zero, then...".
>
>
>I wrote a long essay about the now somewhat boring subject in: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/11757
>
>--anders
>

I read it (and carried forward copies of it).  I have been around since last Feb, and have written a good bit of D code.  I just don't post much.  Did you know D code can randomly deal and find the winner in over 20,000 7-player hands of Texas Hold'em per second keeping stats? (my 700mHz w2k laptop) Makes Monte Carlo a fun thing.  5 times that fast to deal and evaluate 1-player hands.

>
>BTW; I am using Mono for my C# needs. Not that they are many.

Anders F Björklund wrote:
> larry cowan wrote:
> 
>>> Type safety as in C# is more likely first in "D 2.0"
>>
>>
>> No, not "like in C#", type safety is not a MS concept!
> 
> 
> Isn't it? Right after they invented the Internet ? :-)
> 

As a matter of fact, while MS was doing a presentation on Win95, they clearly stated that they didn't believe in the Internet. So they did sure *NOT* invent it!

[snip]
> Barring that, the same kludge as in C99 would have to do:
>
> module std.stdbool;
> alias bit bool;
> const bool true = 1;
> const bool false = 0;

These definitions can go in object.d where "alias bit bool" already exists.
That way "true" and "false" can be removed as keywords and the code in
src/dmd/parse.d
 case TOKtrue:
     e = new IntegerExp(loc, 1, Type::tbit);
     nextToken();
     break;
(similarly for TOKfalse) can be removed. If someone redefines true then the
old true can be obtained by cast(bit)1.

The only reason I can see for keeping true/false as keywords is to help editors that do syntax highlighting of keywords. But that is a pretty weak reason. Another possible reason is that it makes the strict boolean people a tad happier to have true/false as keywords.

[snip]

Ben Hinkle wrote:

> The only reason I can see for keeping true/false as keywords is to help
> editors that do syntax highlighting of keywords. But that is a pretty weak
> reason. Another possible reason is that it makes the strict boolean people a
> tad happier to have true/false as keywords.

I think they should go together...

Either bool/true/false are *all* keywords (as C++), or none are (as C).
And since I think they're good, best would be to add the missing bool ?


The strange part is that "bit" does have some pseudo-boolean qualities.
For instance, it behaves strange when casted from a bigger size integer:

> void main()
> {
>   uint i = cast(uint) 0xFFFFFFFF00000000;
>   short s = cast(ushort) 0xFFFF0000;
>   ubyte b = cast(ubyte) 0xFF00;
>   bit t = cast(bit) 0xFE;
>
>   printf("%ld\n", i);
>   printf("%d\n", s);
>   printf("%d\n", b);
>   printf("%d\n", t ? 1 : 0);
> }

Also shown by:

> void main()
> {
>    bit b;
>    for (int i = -2; i <= +2; i++) {
>      b = cast(bit) i;
>      printf("%+d = %.*s\n", i, b ? "true" : "false");
>    }
> }

-2 = true
-1 = true
+0 = false
+1 = true
+2 = true

That sounds like boolean (i != 0) and not like a bit (i & 1) to me!


This, and the fact that "true" and "false" were of the bit type makes me
think that the built-in D type bit really is our long lost *bool* type ?

And that bit isn't an integer type at all, but instead a boolean type...
Which makes it even more puzzling why the name "bit" was chosen for it ?

--anders

In article <ckmqnk$8c8$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>-2 = true
>-1 = true
>+0 = false
>+1 = true
>+2 = true
>
>That sounds like boolean (i != 0) and not like a bit (i & 1) to me!

This is a bit weird now that I think about it.  If "bit" is supposed to represent a bit, then shouldn't 2 be false, 3 be true, etc?  I grant that this would likely be a significant source of bugs, but logic suggests that bit should behave the same as any other unsigned integer type.

>This, and the fact that "true" and "false" were of the bit type makes me think that the built-in D type bit really is our long lost *bool* type ?
>
>And that bit isn't an integer type at all, but instead a boolean type... Which makes it even more puzzling why the name "bit" was chosen for it ?

Just about.  The only reason I can think to call it "bit" is that it implies a storage size (which is accurte in arrays).


Sean