View mode: basic / threaded / horizontal-split · Log in · Help
October 14, 2004
Bits again. A proposal.
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.
October 14, 2004
Re: Bits again. A proposal.
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
October 14, 2004
Re: Bits again. A proposal.
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.
October 14, 2004
Re: Bits again. A proposal.
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.
October 14, 2004
Re: Bits again. A proposal.
>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!"
October 14, 2004
Re: Bits again. A proposal.
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.
October 14, 2004
Re: Bits again. A proposal.
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!
October 14, 2004
Re: Bits again. A proposal.
[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]
October 14, 2004
Re: Bits again. A proposal.
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
October 14, 2004
Re: Bits again. A proposal.
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
« First   ‹ Prev
1 2 3 4
Top | Discussion index | About this forum | D home