Sounds like we're all just about on the same page.

Walter?

"James McComb" <alan@jamesmccomb.id.au> wrote in message news:c912or$7mt$1@digitaldaemon.com...
> 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" <alan@jamesmccomb.id.au> wrote in message news:c913e1$8ho$1@digitaldaemon.com...
> 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.


It's inefficient. Consider the following boolean sub-expression:

    void *pv = ...

    if(null !== pv)
    {}

That's all ok, and perfectly efficient. The compiler simply tests pv against 0. However, what if we want to remember the expr, as in

    bool b = (null !== pv);

The compiler then has to do the following (assuming 32-bit arch):

    b = (0 != (cast(uint)(pv) & 0xffffffff) ? 1 : 0

This is what happens in C++ with a vast majority of current C++ compilers not warning you about the performance hit. (See "Imperfect C++", in Sept, for the full details for this and other boolean blunders.)

Thus, a boolean type must be the size of the natural int size of the architecture. The only question remains whether we have something special going on for boolean arrays or not. If we do, and if an element in the boolean array is < 1-byte, then there are the addressing problems.

Unless I've seriously missed something in my deliberations on this subject over several years, along with all the people who've opined on this issue on this NG for the last couple of years, there is *no way* to satisfy all the requirements of space efficiency, time efficiency and addressability of a boolean type.

That being the case, maybe the way forward is to have the boolean type the size of the natural int size of the architecture, and have standard library bit container(s)?

Thoughts, everyone?

Matthew wrote:

> Unless I've seriously missed something in my deliberations on this subject over
> several years, along with all the people who've opined on this issue on this NG
> for the last couple of years, there is *no way* to satisfy all the requirements
> of space efficiency, time efficiency and addressability of a boolean type.
> 
> That being the case, maybe the way forward is to have the boolean type the size
> of the natural int size of the architecture, and have standard library bit
> container(s)?
> 
> Thoughts, everyone?

This sounds fine to me.  It's consistent, easy to explain (and thus understand), and convenient for the hardware.

One thing that kind of bugs me, though, is what all those other bits mean.  In a "nice" D application, they would always be unset, but D code doesn't have to be nice. (pointer coersion and so forth) So is the truth value of a bool based on its zero-ness, purely on the lowest bit, or what? (does it even matter?)

 -- andy

"Andy Friesen" <andy@ikagames.com> wrote in message news:c915cr$bv0$1@digitaldaemon.com...
> Matthew wrote:
>
> > Unless I've seriously missed something in my deliberations on this subject
over
> > several years, along with all the people who've opined on this issue on this
NG
> > for the last couple of years, there is *no way* to satisfy all the
requirements
> > of space efficiency, time efficiency and addressability of a boolean type.
> >
> > That being the case, maybe the way forward is to have the boolean type the
size
> > of the natural int size of the architecture, and have standard library bit
> > container(s)?
> >
> > Thoughts, everyone?
>
> This sounds fine to me.  It's consistent, easy to explain (and thus understand), and convenient for the hardware.
>
> One thing that kind of bugs me, though, is what all those other bits mean.  In a "nice" D application, they would always be unset, but D code doesn't have to be nice. (pointer coersion and so forth) So is the truth value of a bool based on its zero-ness, purely on the lowest bit, or what? (does it even matter?)

It would depend on the context.

For boolean sub-expression testing we can use the architecture-width optimistically efficient "if" or "if not". Hence, the following code

    void    *pv =
    int        i    =
    short    s    =

    if(    null === pv &&
           0 == i &&
           0 != s)

would be translatable to (machine speak)

    if(    0 == pv &&     /* This is a 32-bit test, e.g. cmp eax, 0. (Remember,
pv is an int, to the processer) */
           0 == i &&        /* So is this. */
           0 != s)              /* This is a 16-bit test, e.g. cmp ax, 0 */

However, for conversions, which would be explicit, the compiler would have to step in. Consider

    void    *pv = cast(void*)(0xffff0000);
    bit       t     =    cast(boolean)(pv !== null);

If the (second) cast only passed the bit pattern, the truncation error would yield b = 0. Not what we wanted, since the integral value of the boolean sub-expression "pv !== null" is true, which must convert to 1, not 0, in integral form.

This means that the compiler must do the inefficient comparison and value selection mentioned in a previous post, as in

    void    *pv = cast(void*)(0xffff0000);
    bit       t     =    (pv !== null) ? 1 : 0;

This is one more reason, along with logic, and avoidance of errors, why conversions to and from boolean types (and sub-expressions) must be only available with a cast, since they are inefficient.

Walter, you convinced yet?

In article <c9179j$fag$1@digitaldaemon.com>, Matthew says...
>
>
[...]
>
>This is one more reason, along with logic, and avoidance of errors, why conversions to and from boolean types (and sub-expressions) must be only available with a cast, since they are inefficient.
>
>Walter, you convinced yet?

He, he, I think it's just impossible to convince Walter about this. We'll add the boolean type in the first ISO standard draft ;-)

BTW, would you like to add your good argumentation on the wiky page at http://www.wikiservice.at/wiki4d/wiki.cgi?BooleanNotEquBit

Ciao

"Roberto Mariottini" <Roberto_member@pathlink.com> wrote in message news:c91il7$10h8$1@digitaldaemon.com...
> In article <c9179j$fag$1@digitaldaemon.com>, Matthew says...
> >
> >
> [...]
> >
> >This is one more reason, along with logic, and avoidance of errors, why conversions to and from boolean types (and sub-expressions) must be only available with a cast, since they are inefficient.
> >
> >Walter, you convinced yet?
>
> He, he, I think it's just impossible to convince Walter about this. We'll add the boolean type in the first ISO standard draft ;-)

Well, if he wants me to write a book about D, I'm going to be giving my true and honest opinions. ;)

> BTW, would you like to add your good argumentation on the wiky page at http://www.wikiservice.at/wiki4d/wiki.cgi?BooleanNotEquBit

No, but I'm happy for you to quote me, if you have the time.

>> >Walter, you convinced yet?
>>
>> He, he, I think it's just impossible to convince Walter about this. We'll add the boolean type in the first ISO standard draft ;-)

There is another, as yet unmentioned reason, why the type bool should exist, and should NOT be considered arithmetic. How many times have you guys written the following bug into your code? :

>       if (a = b)

instead of:

>       if (a == b)

Show me someone who answers "never", and I'll show you someone who doesn't write software. With a bool type, that bug would be a compile-time error, requiring you to change it to one of:

>       if (a == b)         // if it was a bug, or
>       if ((a = b) != 0)   // if it was deliberate

Convinced yet? There's almost unanimous support for a non-arithmetic bool... Arcane Jill

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c943n8$1mdk$1@digitaldaemon.com...
> >> >Walter, you convinced yet?
> >>
> >> He, he, I think it's just impossible to convince Walter about this. We'll add the boolean type in the first ISO standard draft ;-)
>
> There is another, as yet unmentioned reason, why the type bool should
exist, and
> should NOT be considered arithmetic. How many times have you guys written
the
> following bug into your code? :
>
> >       if (a = b)
>
> instead of:
>
> >       if (a == b)
>
> Show me someone who answers "never", and I'll show you someone who doesn't
write
> software. With a bool type, that bug would be a compile-time error,
requiring
> you to change it to one of:

I agree that we need a real bool type, but have you tried that? It doesn't
work
i get the error message:
E:\Developement\D\Projects\factoriel\factoriel.d(20): '=' does not give a
boolean result
when i try if(a=b)

> >       if (a == b)         // if it was a bug, or
> >       if ((a = b) != 0)   // if it was deliberate
>
> Convinced yet? There's almost unanimous support for a non-arithmetic
bool...
> Arcane Jill

I was allready convinced :)

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c943n8$1mdk$1@digitaldaemon.com...
> >> >Walter, you convinced yet?
> >>
> >> He, he, I think it's just impossible to convince Walter about this. We'll add the boolean type in the first ISO standard draft ;-)
>
> There is another, as yet unmentioned reason, why the type bool should exist,
and
> should NOT be considered arithmetic. How many times have you guys written the following bug into your code? :
>
> >       if (a = b)
>
> instead of:
>
> >       if (a == b)
>
> Show me someone who answers "never", and I'll show you someone who doesn't
write
> software. With a bool type, that bug would be a compile-time error, requiring you to change it to one of:
>
> >       if (a == b)         // if it was a bug, or
> >       if ((a = b) != 0)   // if it was deliberate
>
> Convinced yet? There's almost unanimous support for a non-arithmetic bool... Arcane Jill

I can't say "never", but I can say "not once in the last three years".

See "Imperfect C++" (if you can wait for September 9th; http://www.awprofessional.com/titles/0321228774/) for several different pejorative rants on this topic. ;)

Incidently (and again, this is only a semi-serious suggestion, and I don't care if anyone floors this with a rational argument), is there any reason why the type of the sizeof property has to be int for every type?

I mean, bit.sizeof were to return a float instead of an int, then it could return its conceptual size of 0.125 bytes.

(Of course, malloc(float) and similar would then have to be defined to round up,
not down!)

Jill