On Sun, 19 Feb 2006 11:41:49 +1100, Jarrett Billingsley <kb3ctd2@yahoo.com> wrote:

> "Derek Parnell" <derek@psych.ward> wrote in message
> news:op.s46t2hmc6b8z09@ginger.vic.bigpond.net.au...
>> Wrong! That statement implies that the entire requirements of a correct
>> 'boolean' type is met by the behaviour of the 'bit' type. And that is
>> demonstrably incorrect.
>
> Woah, woah, woah, take it _down_ a notch, Derek!  This is a _boolean data
> type_ we're talking about here, not world politics!  ;)

Huh? There's a difference?  I'm spending too much time here I think.

-- 
Derek Parnell
Melbourne, Australia

Walter Bright wrote:
> "John Stoneham" <captnjameskirk@moc.oohay> wrote in message news:dt7rj2$2lgj$1@digitaldaemon.com...
>> I know that sounds like a complicated description (and it's not complete by any means). And at first glance it sounds limiting in what you can do. But it's really very flexible, and I can't tell you how many bugs it saved me from.
> 
> I believe you. My main concern, though, is that Ada has failed to gain traction in the general programming community. I don't know why this is so, but it makes me very cautious about adopting Ada style. 
> 
> 

Oh I can tell you precisely why it hasn't gained traction in the general programming community (or at least why I personally couldn't stay with it for more than the 5 years I've given it), and there are 2 reasons: 1) For an individual user, the language specification is just *enormous*, and this complaint has nothing to do with the type system (which is my favorite thing about Ada), it has to do with making the "standard library" part of the actual language specification instead of just a library of useful functions which you can use when you need them. It shares this same problem with Common Lisp. 2) The package system is too damn finicky. If you're just wanting to put a utility function in a separate file to be reused later, there are too many little things you have to set up just right to get it to work.

As long as D can avoid these 2 things, I think it will eventually gain a large following.

"Derek Parnell" <derek@psych.ward> wrote in message news:op.s46t2hmc6b8z09@ginger.vic.bigpond.net.au...
> On Sun, 19 Feb 2006 07:39:18 +1100, Walter Bright <newshound@digitalmars.com> wrote:
>
>>
>> "Anders F Björklund" <afb@algonet.se> wrote in message news:dt75m2$243m$2@digitaldaemon.com...
>>> Walter Bright wrote:
>>>> I was thinking of making bool a keyword and basic type along the lines
>>>> of
>>>> bool in C++.
>>> I thought not having a boolean type was part of D's "personality".
>>
>> Boolean was redundant to the bit type.
>
> Wrong! That statement implies that the entire requirements of a correct 'boolean' type is met by the behaviour of the 'bit' type. And that is demonstrably incorrect.

It did nearly every item on your list. Adding another basic type that overlapped 98% with another basic type is just not a good idea. But absent that other type, then it does become a good idea.

On Sun, 19 Feb 2006 19:10:23 +1100, Walter Bright <newshound@digitalmars.com> wrote:

>
> "Derek Parnell" <derek@psych.ward> wrote in message
> news:op.s46t2hmc6b8z09@ginger.vic.bigpond.net.au...
>> On Sun, 19 Feb 2006 07:39:18 +1100, Walter Bright
>> <newshound@digitalmars.com> wrote:
>>
>>>
>>> "Anders F Björklund" <afb@algonet.se> wrote in message
>>> news:dt75m2$243m$2@digitaldaemon.com...
>>>> Walter Bright wrote:
>>>>> I was thinking of making bool a keyword and basic type along the lines
>>>>> of
>>>>> bool in C++.
>>>> I thought not having a boolean type was part of D's "personality".
>>>
>>> Boolean was redundant to the bit type.
>>
>> Wrong! That statement implies that the entire requirements of a correct
>> 'boolean' type is met by the behaviour of the 'bit' type. And that is
>> demonstrably incorrect.
>
> It did nearly every item on your list. Adding another basic type that
> overlapped 98% with another basic type is just not a good idea. But absent
> that other type, then it does become a good idea.

I note my "entire" and your "nearly" <g>. But thank you, Walter. What didn't you deem worthy?

By the way, is there anything else I can 'specify' for you?


-- 
Derek Parnell
Melbourne, Australia

John Stoneham wrote:
> This is one thing I really like about Ada. The compiler will just not let you do ANYTHING with a type that requires any kind of implied cast. Boolean is Boolean and nothing else. If you've got a Boolean variable, you can't add an integer to it, you can't assigned anything other than another Boolean to it, and you can't use anything other than a Boolean in it's place.

That's indeed how a type safe language should behave. Fine examples are statically typed functional languages Haskell and O'Caml, which are *absolutely* type-safe. That is, they have very clear and strict type rules with no casts. In Haskell converting a truth value to integer is done via the obvious approach:

b = true
i = if b then 1 else 0

Also you can just forget about accidentally mixing signed and unsigned values :) This hasn't really bothered me at all while programming in Haskell or O'Caml. I would gladly exchange "easy boolean to integer conversion" you people seem to appreciate so much for type safety.

-- 
Niko Korhonen
SW Developer

In article <dt36tu$1lg3$2@digitaldaemon.com>, Walter Bright says...
>
>I think the basic type bit has been a failure. It's a substantial increase in the compiler and runtime complexity to support it. Nobody seems happy about bit being a boolean type. There's no reasonable way to take a pointer to a bit, meaning that out and inout bit parameters are inconsistent and kludgy.
>
>Should bit and bit[] be removed before 1.0?
>
>There is a place for bit[] as a library type, though.
>
>So what do people think?

If it's that complex to implement bit[], a library seems fine to me.

But if you're tossing "bit" for being ugly, it should be to replace it with something cleaner, with equal or better performance.  Is there a replacement for bit that works as well and doesn't require implicit (x ? 1 : 0) branches inserted everywhere?

I think the worst thing would be to have a language designed by the influence of the people who complained.  I think Java got rid of unsigned types for this reason.  Every CPU you can buy supports unsigned, but Java can't.

*All* low level programming has to deal with ugly, machine oriented realities. This will always bother some people.

But I think 80% of user complaints are driven not by real design motivations, but by the "surprise" principle:  "Why doesn't it work the way I guessed it would?"

This principle makes perfect sense at the high level (web page) but not at the hardware level.  Software can be beautiful, but not "too beautiful for this world".  If D gets the low level stuff right, it *has* to have ugly parts that are fast a la C rather than pretty parts that are slow al la Java, in at least a few, unremovable cases.

Is "bit" or "bool" one of these?

Kevin

"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message news:dtjekm$126q$1@digitaldaemon.com...
> I think the worst thing would be to have a language designed by the
> influence of
> the people who complained.

LOL. I agree.

> *All* low level programming has to deal with ugly, machine oriented
> realities.
> This will always bother some people.

Yes. D has to work with the reality. Java got into a lot of trouble with floating point because the spec ignored the reality of FPU hardware. The spec got subsequently revised.

> Is "bit" or "bool" one of these?

It turns out that a BitArray struct can pretty much cover nearly all the uses for bit[].

Kevin Bealer wrote:
> 
> But I think 80% of user complaints are driven not by real design motivations,
> but by the "surprise" principle:  "Why doesn't it work the way I guessed it
> would?"

There's something to be said for predictability.  It doesn't have to be a slippery slope :-)

> This principle makes perfect sense at the high level (web page) but not at the
> hardware level.  Software can be beautiful, but not "too beautiful for this
> world".  If D gets the low level stuff right, it *has* to have ugly parts that
> are fast a la C rather than pretty parts that are slow al la Java, in at least a
> few, unremovable cases.
> 
> Is "bit" or "bool" one of these?

I don't think so.  I find that the inability to address array-stored bits causes me more trouble than is worth the benefits.  Particularly considering that an equivalent library class could be created which provides similar performance characteristics.


Sean

Walter Bright wrote:
> I think the basic type bit has been a failure. It's a substantial increase in the compiler and runtime complexity to support it. Nobody seems happy about bit being a boolean type. There's no reasonable way to take a pointer to a bit, meaning that out and inout bit parameters are inconsistent and kludgy.
> 
> Should bit and bit[] be removed before 1.0?
> 
> There is a place for bit[] as a library type, though.
> 
> So what do people think? 

Something I didn't see anyone mention is the fact that 'bit' isn't really a native CPU type. x86 doesn't have any instructions that operate on bits per se, except for the carry flag. Everything else is operations on bits within integers. Bits are like quarks: everything is made out of them, but you can never see one on its own.
I think D has been pretending that there's such a thing as an isolated bit, the same mistake that C++ made with vector<bool>. It's an illusion that's too costly to maintain.

Walter Bright wrote:
> I think the basic type bit has been a failure. It's a substantial increase in the compiler and runtime complexity to support it. Nobody seems happy about bit being a boolean type. There's no reasonable way to take a pointer to a bit, meaning that out and inout bit parameters are inconsistent and kludgy.
> 
> Should bit and bit[] be removed before 1.0?
> 
> There is a place for bit[] as a library type, though.
> 
> So what do people think?

I was just thinking about my BitArray stuff in my utility library

http://pr.stewartsplace.org.uk/d/sutil/

and looking again at how it's implemented.  It doesn't use D's bit arrays internally, so the only implication for the library really is getting rid of the conversions to and from them.  (And debugging the big-endian implementation logic!)

But it's worth looking at it before reinventing the wheel, at least for those of you who haven't already reinvented the wheel.... :-)

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.