In article <opspjwg8y923k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>On Wed, 20 Apr 2005 13:16:27 -0500, Joshua Cearley <jtech@ezoob.com> wrote:
>> the only reason I can think of ever wanting a String type is for OO. You would be able to say ThisIsSomeString.strip() like you can in Ruby or Java.
>
>And D:
>
>char[] strip(char[] input) {}
>char[] a;
>char[] b;
>b = a.strip();
>
>It's a lovely little feature of arrays. I'm hoping it's extended to 'int' etc.
>
>Regan

That's pretty neat; is it documented anywhere?

Kevin

On Fri, 22 Apr 2005 05:41:38 +0000 (UTC), Kevin Bealer <Kevin_member@pathlink.com> wrote:
> In article <opspjwg8y923k2f5@nrage.netwin.co.nz>, Regan Heath says...
>>
>> On Wed, 20 Apr 2005 13:16:27 -0500, Joshua Cearley <jtech@ezoob.com> wrote:
>>> the only reason I can think of ever wanting a String type is for OO. You
>>> would be able to say ThisIsSomeString.strip() like you can in Ruby or
>>> Java.
>>
>> And D:
>>
>> char[] strip(char[] input) {}
>> char[] a;
>> char[] b;
>> b = a.strip();
>>
>> It's a lovely little feature of arrays. I'm hoping it's extended to 'int'
>> etc.
>>
>> Regan
>
> That's pretty neat; is it documented anywhere?

Not to my knowledge.

Regan

Derek Parnell wrote:

> Its a confusion between implementation and theory. 

This was *all* about the implementation, as in "right now in D"

> bit is a number value. Semantically speaking, it makes sense to do
> arithmetic on numbers, and it doesn't make sense to test the truth of a
> number.

No, that is not how it is implemented. "bit" is a boolean value,
it is not one of the integer types. (and as you know, D defines
the "truth" of both integers and pointers, so that's kinda moot)

[In theory, I do prefer my bits to be 1 or 0 (or "on" and "off")]

> bool is a truth value. Semantically speaking, it doesn't make sense to do
> arithmetic on truths, and does make sense to test the truth of a truth.

I prefer to use the term "boolean", when talking about the Real Thing.
(just as I use terms "integer" and "floating point", and even "strings")

[In theory, the regular boolean concept only has values true and false.]

"bool" is the right keyword, but it does suffer from the same problem as
in C++, in that it can be used in arithmetic contexts (C# fixed this...)

Then again, "bool" is not a keyword in C and D but just a typedef/alias?

> However, Walter has decided to *implement* bool as if it was the same as a
> bit. Which allows coders to do stupid things like ...

That code worked similar in C99/C++ too:

#include <stdio.h>
#include <stdbool.h>

int main()
{
  int a;

  a = 2*true + false;

  bool b;
  b = 1;
  b++;

  bool c;
  c = (bool)2;
  c = (bool)-2;
  printf("%d %d %d %d\n", a, b, b+1, c);

  return 0;
}

So just *having* such a boolean type is not enough to "enforce" it ?
(for that purpose, D's bit type is "boolean enough" - just as _Bool)

Enforcing it means:

bool.cs(8) error CS0029: Cannot convert implicitly from `bool' to `int'
bool.cs(8) error CS0019: Operator * cannot be applied to operands of type `int' and `bool'
bool.cs(11) error CS0031: Constant value `1' cannot be converted to bool
bool.cs(12) error CS0187: No such operator '++' defined for type 'bool'
bool.cs(15) error CS0030: Cannot convert type 'int' to 'bool'
bool.cs(16) error CS0030: Cannot convert type 'int' to 'bool'

Those are the errors you get, when compiling (something similar) in C#.

> One would have thought that a smart compiler could have just said - "Hey!
> That doesn't make any sense. Do it properly."

I think Walter preferred that it worked the same way that it did in C.
(as opposed to changing it, like they did with Java and later C# too)

Which means that we will continue to see arithmetic logic. And since
we will do, there is really not much point in separating bit and bool ?

But I still don't see much use for "bit", except for the venerable bit[]

> The belief is that if bool is implmented as a bit, then the compiler can
> create some optimised machine code. What isn't so strongly believed, is
> that one can do that *in addition* to better compiler type checking.

This is not true. "bit"/byte is just the smallest, not the fastest type.
If that was the reason for choosing bit, why does opEquals return "int"?

I thought it would be *easier* to optimize booleans that were not of a
fixed size, but of course that also means much trickier API definitions.
(at least "bit" has a fixed size of 1, when not being part of arrays -
unlike C++ where the size of a "bool" varies with the tide of the moon)

"bit" is just the default boolean type, like "char[]" is for strings ?
But in full reality, D has three boolean types and three string types:

See http://www.prowiki.org/wiki4d/wiki.cgi?BitsAndBools
and http://www.prowiki.org/wiki4d/wiki.cgi?CharsAndStrs

At least you can do binary comparisons of booleans in D, which wasn't
possible in ancient C - unless comparing with false (which is always 0)
i.e. if you a have a "bool b;", you can say: "if (b == true) { ... }"
Since you now know that the only "true" value of a bit will be true (1).
But that's how it works in C99 / C++ too, so not much of an improvement.

>>Oh well, that's been decided since long. Time to move on, for sure.
>>I'll try not to mutter, when next newcomer to D wonders about this...
> 
> True, or should I say 1 ;-)

"true" or "cast(bool) 1", you mean ;-) Otherwise you could get warnings
about "possible loss of data" when converting from int to bool, right ?

--anders

On Fri, 22 Apr 2005 10:53:43 +0200, Anders F Björklund wrote:

> Derek Parnell wrote:
> 
>> Its a confusion between implementation and theory.
> 
> This was *all* about the implementation, as in "right now in D"

Huh? What have you been smoking?

>> bit is a number value. Semantically speaking, it makes sense to do arithmetic on numbers, and it doesn't make sense to test the truth of a number.
> 
> No, that is not how it is implemented. "bit" is a boolean value, it is not one of the integer types. (and as you know, D defines the "truth" of both integers and pointers, so that's kinda moot)

Where did I say "bit is an integer"? I said "bit is a *number* value". In
other words, 'bit' is a numeric value. Just as integers and floating point
values are numeric values. And because they are numeric, it makes sense to
do numeric type operations, such as arithmetic with them.

> [In theory, I do prefer my bits to be 1 or 0 (or "on" and "off")]

Of course. A 'bit' is a numeric value that can have only two distinct values - zero and one. You will note that "on" is a two-character string and not a number ;-)

>> bool is a truth value. Semantically speaking, it doesn't make sense to do arithmetic on truths, and does make sense to test the truth of a truth.
> 
> I prefer to use the term "boolean", when talking about the Real Thing. (just as I use terms "integer" and "floating point", and even "strings")

That's nice, but so what????

> [In theory, the regular boolean concept only has values true and false.]
> 
> "bool" is the right keyword, but it does suffer from the same problem as in C++, in that it can be used in arithmetic contexts (C# fixed this...)

Yes, that's what I just said.

> Then again, "bool" is not a keyword in C and D but just a typedef/alias?

So?

>> However, Walter has decided to *implement* bool as if it was the same as a bit. Which allows coders to do stupid things like ...
> 
> That code worked similar in C99/C++ too:

So? That just makes C99 and C++ just as stupid as D, in respect to the concept of boolean values.

[snip]

> So just *having* such a boolean type is not enough to "enforce" it ? (for that purpose, D's bit type is "boolean enough" - just as _Bool)
> 
> Enforcing it means:
> 
> bool.cs(8) error CS0029: Cannot convert implicitly from `bool' to `int'
> bool.cs(8) error CS0019: Operator * cannot be applied to operands of
> type `int' and `bool'
> bool.cs(11) error CS0031: Constant value `1' cannot be converted to bool
> bool.cs(12) error CS0187: No such operator '++' defined for type 'bool'
> bool.cs(15) error CS0030: Cannot convert type 'int' to 'bool'
> bool.cs(16) error CS0030: Cannot convert type 'int' to 'bool'
> 
> Those are the errors you get, when compiling (something similar) in C#.

Yes, exactly what I was saying. In D the 'bool' does not implement the true
boolean concept. It is a hybrid that implements some boolean aspects but
not all.

>> One would have thought that a smart compiler could have just said - "Hey! That doesn't make any sense. Do it properly."
> 
> I think Walter preferred that it worked the same way that it did in C. (as opposed to changing it, like they did with Java and later C# too)

Yes, so what? Does that make DMD a smart compiler?

> Which means that we will continue to see arithmetic logic. And since we will do, there is really not much point in separating bit and bool ?

I agree that because Walter cannot see fit to implement a true boolean, that it is no point in discussing it in order to influence Walter. It isn't going to happen. However, there is no problem discussing it in terms of programming concepts.

> But I still don't see much use for "bit", except for the venerable bit[]


>> The belief is that if bool is implmented as a bit, then the compiler can create some optimised machine code. What isn't so strongly believed, is that one can do that *in addition* to better compiler type checking.
> 
> This is not true. "bit"/byte is just the smallest, not the fastest type. If that was the reason for choosing bit, why does opEquals return "int"?

True. What I should have said was "... bool is implemented as a numeric value ...".

-- 
Derek Parnell
Melbourne, Australia
23/04/2005 12:28:58 AM

Derek Parnell wrote:

>>This was *all* about the implementation, as in "right now in D"
> Huh? What have you been smoking?

Sorry, "in this thread" (there has been a few)

> Where did I say "bit is an integer"? I said "bit is a *number* value". In
> other words, 'bit' is a numeric value. Just as integers and floating point
> values are numeric values. And because they are numeric, it makes sense to
> do numeric type operations, such as arithmetic with them.

I know, I know... I meant the bit _type_ there.

> Of course. A 'bit' is a numeric value that can have only two distinct
> values - zero and one. You will note that "on" is a two-character string
> and not a number ;-)

It was a constant... But I wouldn't call them "true" and "false" as my
first choices, similar to as I wouldn't guess the type of them as "bool"

>>Then again, "bool" is not a keyword in C and D but just a typedef/alias?
> 
> So?

An old pet peeve... D has keywords "true" and "false", but *not* "bool"?

> So? That just makes C99 and C++ just as stupid as D, in respect to the
> concept of boolean values.

It does... Or D "no smarter", depending on how you see it.

> Yes, exactly what I was saying. In D the 'bool' does not implement the true
> boolean concept. It is a hybrid that implements some boolean aspects but
> not all.

No argument there.

>>Which means that we will continue to see arithmetic logic. And since
>>we will do, there is really not much point in separating bit and bool ?
> 
> I agree that because Walter cannot see fit to implement a true boolean,
> that it is no point in discussing it in order to influence Walter. It isn't
> going to happen. However, there is no problem discussing it in terms of
> programming concepts.

OK. I'll settle for using "bool" and "true" and "false", in D.

--anders

Anders F Björklund wrote:

>> Of course. A 'bit' is a numeric value that can have only two distinct
>> values - zero and one. You will note that "on" is a two-character string
>> and not a number ;-)
> 
> It was a constant... But I wouldn't call them "true" and "false" as my
> first choices, similar to as I wouldn't guess the type of them as "bool"

"wouldn't guess the type of true and false as bit", it should have read

:-P

--anders

Derek Parnell wrote:

> Yes, exactly what I was saying. In D the 'bool' does not implement the true
> boolean concept. It is a hybrid that implements some boolean aspects but
> not all.

Sorry if I repeated some of your earlier stated opinions,
I was just trying to giving some more examples and details.

>>I think Walter preferred that it worked the same way that it did in C.
>>(as opposed to changing it, like they did with Java and later C# too)
> 
> Yes, so what? Does that make DMD a smart compiler?

Not in this aspect, no it doesn't. Then again, if the D compiler
had flagged it as illegal a lot of current D code wouldn't pass.

That was not a problem then, but it's getting to be one as more
and more D code is being developed. But it *could* be an optional
warning, just like the warnings about "might cause loss of data" ?
And use the "bool" alias and the "true/false" constants, and pretend.

> I agree that because Walter cannot see fit to implement a true boolean,
> that it is no point in discussing it in order to influence Walter. It isn't
> going to happen. However, there is no problem discussing it in terms of
> programming concepts.

One advantage is that code using bool-as-a-separate-type will
continue to compile, with the less restrictive DMD compiler.

So it would be possible to either add these as warnings, or if
that is not welcome one could add it to a separate "dlint" program.

And then you could run with warnings / preprocess, to make it
behave as if it wasn't allowed to compare "bool" with others...

I'm not sure how much work writing such a utility would be,
and it sure would be a lot easier if it was in DMD already.


Another minor problem is that some language constructs in D
are genuinely ugly without the implicit boolean contexts...

Such as "((key in hash) !== null)" and various assert forms.
"assert(false);" "assert(!(object is null));" and so on.

--anders

Just a thought, since a signed bit numeric type would have the values "-1" and "0" possible,
I can understand using a boolean representation instead of a signed bit...
However, an unsigned bit (ubit) would have 0 and 1 as values.

This should satisfy the desire to have an arithmetic bit type.

TZ

"Anders F Björklund" <afb@algonet.se> wrote in message news:d4ae2p$223g$1@digitaldaemon.com...
> Derek Parnell wrote:
>
> > Its a confusion between implementation and theory.
>
> This was *all* about the implementation, as in "right now in D"
>
> > bit is a number value. Semantically speaking, it makes sense to do arithmetic on numbers, and it doesn't make sense to test the truth of a number.
>
> No, that is not how it is implemented. "bit" is a boolean value, it is not one of the integer types. (and as you know, D defines the "truth" of both integers and pointers, so that's kinda moot)
>
> [In theory, I do prefer my bits to be 1 or 0 (or "on" and "off")]
>
> > bool is a truth value. Semantically speaking, it doesn't make sense to do arithmetic on truths, and does make sense to test the truth of a truth.
>
> I prefer to use the term "boolean", when talking about the Real Thing. (just as I use terms "integer" and "floating point", and even "strings")
>
> [In theory, the regular boolean concept only has values true and false.]
>
> "bool" is the right keyword, but it does suffer from the same problem as in C++, in that it can be used in arithmetic contexts (C# fixed this...)
>
> Then again, "bool" is not a keyword in C and D but just a typedef/alias?
>
> > However, Walter has decided to *implement* bool as if it was the same as a bit. Which allows coders to do stupid things like ...
>
> That code worked similar in C99/C++ too:
>
> #include <stdio.h>
> #include <stdbool.h>
>
> int main()
> {
>    int a;
>
>    a = 2*true + false;
>
>    bool b;
>    b = 1;
>    b++;
>
>    bool c;
>    c = (bool)2;
>    c = (bool)-2;
>    printf("%d %d %d %d\n", a, b, b+1, c);
>
>    return 0;
> }
>
> So just *having* such a boolean type is not enough to "enforce" it ? (for that purpose, D's bit type is "boolean enough" - just as _Bool)
>
> Enforcing it means:
>
> bool.cs(8) error CS0029: Cannot convert implicitly from `bool' to `int'
> bool.cs(8) error CS0019: Operator * cannot be applied to operands of
> type `int' and `bool'
> bool.cs(11) error CS0031: Constant value `1' cannot be converted to bool
> bool.cs(12) error CS0187: No such operator '++' defined for type 'bool'
> bool.cs(15) error CS0030: Cannot convert type 'int' to 'bool'
> bool.cs(16) error CS0030: Cannot convert type 'int' to 'bool'
>
> Those are the errors you get, when compiling (something similar) in C#.
>
> > One would have thought that a smart compiler could have just said - "Hey! That doesn't make any sense. Do it properly."
>
> I think Walter preferred that it worked the same way that it did in C. (as opposed to changing it, like they did with Java and later C# too)
>
> Which means that we will continue to see arithmetic logic. And since we will do, there is really not much point in separating bit and bool ?
>
> But I still don't see much use for "bit", except for the venerable bit[]
>
> > The belief is that if bool is implmented as a bit, then the compiler can create some optimised machine code. What isn't so strongly believed, is that one can do that *in addition* to better compiler type checking.
>
> This is not true. "bit"/byte is just the smallest, not the fastest type. If that was the reason for choosing bit, why does opEquals return "int"?
>
> I thought it would be *easier* to optimize booleans that were not of a fixed size, but of course that also means much trickier API definitions. (at least "bit" has a fixed size of 1, when not being part of arrays - unlike C++ where the size of a "bool" varies with the tide of the moon)
>
> "bit" is just the default boolean type, like "char[]" is for strings ? But in full reality, D has three boolean types and three string types:
>
> See http://www.prowiki.org/wiki4d/wiki.cgi?BitsAndBools
> and http://www.prowiki.org/wiki4d/wiki.cgi?CharsAndStrs
>
> At least you can do binary comparisons of booleans in D, which wasn't possible in ancient C - unless comparing with false (which is always 0) i.e. if you a have a "bool b;", you can say: "if (b == true) { ... }" Since you now know that the only "true" value of a bit will be true (1). But that's how it works in C99 / C++ too, so not much of an improvement.
>
> >>Oh well, that's been decided since long. Time to move on, for sure. I'll try not to mutter, when next newcomer to D wonders about this...
> >
> > True, or should I say 1 ;-)
>
> "true" or "cast(bool) 1", you mean ;-) Otherwise you could get warnings
> about "possible loss of data" when converting from int to bool, right ?
>
> --anders