NewsForumsCodeLogsGallerySpecsSearch

Why is there no Bool Type?

BlitzMax Forums/BlitzMax Programming/Why is there no Bool Type?

PetBom(Posted 2005) [#1]
Lack of time made me decide not to get into BlitzMax before it was officially out of beta for Windows, even though I bought it upon release.

Since the above is true, as of a couple of hours I've started too look into it. First impressions are good. (Ok...they might not be exactly first, I have cheated a bit and had a few quick looks), but It's the first time I've actually coded something. Though it's not a 'real' problem I'm just wondering why there is no 'bool' type?


Global playerName:String = "Adam"
Global playerAge:Int = 33
Global isPlayerAlive:Bool



This, in my mind, is a lot prettier than:


Global playerName:String = "Adam"
Global playerAge:Int = 33
Global isPlayerAlive:Byte '<< Or Short or Int...



From a functional point of view it has really no meaning, but most modern 00 languages has booleans as a distinct type for the sake of human readability. Why not BMax?

//PetBom


FlameDuck(Posted 2005) [#2]
All integer types can be interpreted as "bool" types, as can the result of all operators. A zero result means True, non-zero is False.

For the sake of human readability you can use the Keywords "True" and "False" to set boolean values just like in every other language.

This is much more flexible IMHO.


(tu) ENAY(Posted 2005) [#3]
I'd like to have Bools too as using an int to store bools can often lead to haphazard logic.

Such as:-

Local moo:Int

moo = True

If moo = 1 Then

Endif


It's surely better memory management too when you only need a single bit to store the result instead of storing an entire int.

I WANT MY BOOL! ;)


FlameDuck(Posted 2005) [#4]
I'd like to have Bools too as using an int to store bools can often lead to haphazard logic.
In most languages you can do that with bools too.

It's surely better memory management too when you only need a single bit to store the result instead of storing an entire int.

I WANT MY BOOL! ;)
FYI bools are traditionally stored as whatever type matches the width of the databus. So memory management isn't much of an issue, although I suppose it could theoretically speed up some code in extreme situations where people where using Ints but running on a 64bit machine (Mac or Athlon).


MrCredo(Posted 2005) [#5]
a bool-variable take 1 byte memory... so i think this s useless... more interesting is to have signed+unsigned variables


PetBom(Posted 2005) [#6]
For the sake of human readability you can use the Keywords "True" and "False" to set boolean values just like in every other language.


Yes, but that is not really the what I'm talking about. The point I'm trying to make is that when you specify type of a variable you create, the typing has more than purely functional effects. It also implies how the variable is to be used. To give you an example:

Say that somebody writes a pice of code that I'm supposed to continue working with. If that somebody has created a variable, and explicitly has set it to be of bool type, this will automaticly give me an idea of how and for what the variable is to be used. Knowing that a variable is an Int does not implicitly tell me it's intended use.

c#,java, c++ and these days VB.Net would function perfectly without a specific boolean type, but they have all implemnted it. Not from a functional point of view, but from a structural.

If you're working with visual modeling of code (UML etc.) a distinct boolean type is necessary to enable smooth transition from model to code. Constraints are mostly expresed as booleans in visual models. Not having a explicit implementation of them in the target language is, in my mind, a drawback.

For the "lone-coder" I guess that this is a minor problem. But in a team, where you are dependant on each others code, It's really important that you can communicate your ideas and implementations on a structural level (via models, interfaces, transports etc.) That is why you need data types. So that someone else will understand what the hell I'm talking about. Stating that, for instance, a specific property in a class is a bool will automaticly tell another user that it will be used to find out if a certain condition is true or false and cannot be used in another way. Even if he just has access to the class via an interface and can see nothing of the implementation he can still understand a lot more about the class.

And as ENAY says, you save 7 bits :)

//PetBom


Who was John Galt?(Posted 2005) [#7]
>0 = true
0 = false

You can do...

If moo>0
'moo is true
endif

..or even more readable IMO...

if moo
'moo is true
endif


(tu) ENAY(Posted 2005) [#8]
I'm more concerned that if you did this:-
moo = True

and then later on you accidentally did this:-
moo = 2

and then this wouldn't work
Select moo
Case False
Case True
End Select


Where as if it were a bool you'd probably get an error telling you "What the hell are you doing trying to store a number that isn't 0 or 1 into a Bool!" ERROR! :)


ImaginaryHuman(Posted 2005) [#9]
So do

Select moo
Case 0
Case <>0
End Select


Eikon(Posted 2005) [#10]
Booleans would be nice, and I was suprised that they weren't included.


Ryan Moody(Posted 2005) [#11]
Couldn't you create your own boolean type?

Ryan


Steve Elliott(Posted 2005) [#12]
Yeah I agree bool should be added.


FlameDuck(Posted 2005) [#13]
and then this wouldn't work
Maybe not, but this would:
Select moo
Case True
	Print "moo is True"
Default
	Print "moo is False"
End Select
End
Anyhow since you're dealing with a boolean type, there not much point in making a select statement. Just go
If moo = True
	Print "moo is True"
Else
	Print "moo is False"
End If
Since you *know* for a fact that moo is supposed to be a boolean, and then by definition only has 2 states, there is no need for any extra logic to determine what number it actually is - all that's important is that it isn't 0 (aka. True).
Constraints are mostly expresed as booleans in visual models.
In my experience they're mostly expressed as states, as in "you're allowed to do this, if you're in this, this or this state" but I suppose different people model things differently.
And as ENAY says, you save 7 bits :)
No. Fetching a byte is actually slower than fetching an int. Shifting and anding a byte, to get the bit you want is even slower.


GW(Posted 2005) [#14]
Flameduck

A zero result means True, non-zero is False.



uh? wha..?


Tiger(Posted 2005) [#15]
What I know is zero False and non-zero is True.


CS_TBL(Posted 2005) [#16]
zero=true, in assembly :)


Cajun17(Posted 2005) [#17]
Because the check is simply first-second so if the difference is 0 they're equal.
In higher level languages it's switched because it's more logical to have 0 or Null equal false for numbers and objects.


FlameDuck(Posted 2005) [#18]
In higher level languages it's switched because it's more logical to have 0 or Null equal false for numbers and objects.
Wow! I hadn't even noticed - and I've been using mostly high-level languages since 1998!

Goes to show how much of a problem this really is doesn't it? A guy can program for nearly 7 years without ever running into it! Oh yes, this needs to be addressed at once! :o>


marksibly(Posted 2005) [#19]
Hi,

I didn't do a bool type because I didn't think it added enough to be worth the extra complexity.

For example, stuff like "If k..." then becomes "If k<>0..." and so on, and I actually prefer the 'lazy' version - I find it more readable!

And to be honest, I've never really run into many (any?) problems in any language due to the lack of a bool type.


PetBom(Posted 2005) [#20]
In my experience they're mostly expressed as states, as in "you're allowed to do this, if you're in this, this or this state" but I suppose different people model things differently.

Yes, exactly. But then you need a property or method that can return an answer to the question wich state something is in, e.g. isInThatStare() returns true or false. The point of visual modeling get a map of what your objects or classes must do. If a constraint tells you that something must be in a certain state, you must add something to be able to meet the demands of the constraint.

I didn't do a bool type because I didn't think it added enough to be worth the extra complexity.

Fair enough. That answers my original question, "Why is there no Bool Type".

As I said in the begining, this is not a 'real' problem, more of an esthetic one. I guess it's mostly a matter of how my mind works. If I add a property that I only want a true or false reply from I automaticly think "bool", and declaring it as such adds an extra confidecene that my logic is right. As mentioned above, i do not have a problem with it from a functional perspective.

I'll survive without a bool type :)


Perturbatio(Posted 2005) [#21]
it's a pity you can't do something like:

Type BOOL : Int


or 
Type BOOL extends Int



Scienthsine(Posted 2005) [#22]
I hate adding extra types that are basically the same. IE: Win32/.NET crap. I hate trying to pass a value to a function, only to error out and have to go and 'cast' something that internally is just a freakin' Int anyway.... *Mutter*