Boolean Data Type in freebasic

General discussion for topics related to the FreeBASIC project or its community.
Post Reply
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Boolean Data Type in freebasic

Post by coderJeff »

Just the other day, I was working on the boolean data type for freebasic, then got *really* busy for, like, 8 years. Now, I have been working on it again. Thanks to the efforts of counting_pine and dkl, they have raised that initial work from the depths of the fbc repo, and with their continuing help over last 2 months, I think it is now at a good place to merge in with current fbc master. I am posting here to offer information about the feature, an opportunity for comment, and to try answering as many questions as I can about it (hopefully intelligently).

First, why a boolean data type in freebasic? QB never had it...
1) As an abstraction of data that can be in only one of two states, true or false, it is useful.
2) It is inconvenient (as in practically impossible) to interface with C++ libraries without a bool type (lookup 'name mangling' if you want to know why). Many other constructs in C++ are representable in FB, but not boolean.

Keywords added to support boolean (with links to wiki):
BOOLEAN - this is the name of the data type that can hold the values FALSE and TRUE
CBOOL() - a function that converts expressions to the boolean data type
FALSE/TRUE - intrinsic constants that represent values of the boolean data type

Conflicts:
No doubt, adding BOOLEAN, CBOOL, FALSE, and TRUE, to the global namespace is going to cause some conflicts with existing code. Here's what to expect:
- These keywords can be #undef'ined as needed to suppress conflicts
- Could add #ifdef/#endif guards on existing defintions
- Could move existing TRUE/FALSE definitions to a NAMESPACE or TYPE where they won't conflict with the global intrinsic definitions
- To help ease the pain of duplicate definitions, FALSE/TRUE can be redefined once, producing a compiler warning only. Eventually, in some future version of fbc, this warning will become a normal dupicate definition error.
- warnings when comparing booleans with constants that are not boolean
- warnings when mixing booleans and some other data type in some operations

FB Runtime Library:
freebasic statements/functions like PRINT, INPUT, READ, DATA, WRITE, PRINT USING, etc, support the boolean type.

Internals:
- In memory, a boolean value has a width of 8 bits where 0 represents the FALSE value and 1 represents the TRUE value. All other values are undefined.
- 0 or 1 in memory works well for compatability with C++ libraries
- When a boolean is converted to integer, 0 or 1 boolean value becomes 0 or -1 integer value. This works well with freebasic comparison operators and bitwise (logic) operators.
- unary and binary operators operating on binary operands only, return a boolean result.
- forcing values in to the boolean data type (using unions or pointers) are likely to cause undesired results
- the 'boolean' version of fbc compiler needs a (partially) working CBOOL() function. It uses "#define cbool(x_) iif((x_),-1,0))" to bootstrap
- fbc compiler (internally) uses FALSE=0, TRUE=-1 integers to represent booleans, therefore FALSE and TRUE intrinsic booleans are undefined internally and the integer versions are used instead.

---
Looking forward to your comments! Thanks!
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: Boolean Data Type in freebasic

Post by caseih »

I'm all for it!

Now if you are intending this boolean to be workable with C++ classes, you'll have to adopt the same storage representation as C++ does, will you not (g++ usually)? Even worse, different C++ compilers represent bool differently. But FB can only handle g++ name mangling symbols, right? Or can it deal with Visual C++ as well? Typically a C++ bool is the same size as int though.

Historically, because BASIC chose to not have logical operators, the results of boolean binary operations such as <,>,>=,<=,<> and = all returned -1 or 0, so that bitwise operators would have the same affect as the missing logical operators. So when cast to a number, True needs to turned into -1 and False needs to be castable to 0, to maintain this sort of behavior. C++, on the other hand, though it does not define the in-memory representation, when casting to an int always converts true to 1 and false to 0, though I'm not sure this would impact fbc or programmers in any way.
marcov
Posts: 3454
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: Boolean Data Type in freebasic

Post by marcov »

Maybe also have an option to make it 32-bit for GTK gboolean ? ( :-) )
Tourist Trap
Posts: 2958
Joined: Jun 02, 2015 16:24

Re: Boolean Data Type in freebasic

Post by Tourist Trap »

coderJeff wrote:(...)
Hello. I have first been surprised not to find boolean in fb. But after a short time I've noticed that if booleans were useful (for me for compatibility with vb.net which I use casually), it was however not necessary to add them as a part of the core language. They rather can be added (at different implementation depth) as standalone UDT. What one may do maybe is offering a full boolean UDT definition with all operators overload, properties, useful extensions, and so on.

The fact is that UDT are very versatile, and once a base defined, can be extended depending on the needs. For instance, I've been using 'Nullable Object' under vb.net, and was able to get nullable booleans, which is a way to get a boolean with 3 values, null, true and false. Nobody would think of such an object to come hardwired in the language.

Same is true for complex numbers.

So to say, I think that since FB offers object capabilities, and will increase them in the future, now defining some types would be perfectly done with an UDT. Put it in an external lib then, and up to whoever to link it or no. That also solves immediatly backward compatibility concern. But that remains hard work, since providing a good object imply some work.
Last edited by Tourist Trap on Jul 22, 2015 11:52, edited 1 time in total.
marcov
Posts: 3454
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: Boolean Data Type in freebasic

Post by marcov »

Tourist Trap wrote:
coderJeff wrote:(...)
Hello. I have first been surprised not to find boolean in fb. But after a short time I've noticed that if booleans were useful (for me for compatibility with vb.net which I use casually), it was however not necessary to add them as a part of the core language. They rather can be added (at different implementation depth) as standalone UDT
So how are you going to prohibit assigning a numerical value other than the ones corresponding to true and false to them, (or passing to parameter of the type) ? How do you make conditional expressions assignable to them? (does a<b return an int value, like in C, or a boolean like in pascal?)
Tourist Trap
Posts: 2958
Joined: Jun 02, 2015 16:24

Re: Boolean Data Type in freebasic

Post by Tourist Trap »

marcov wrote:So how are you going to prohibit assigning a numerical value other than the ones corresponding to true and false to them, (or passing to parameter of the type) ?
To filter entries and outputs, use properties and make inner fields private. Example you assign booleanUdt.value = 17.21. This can be filtered by the value() set-property and the inner field turned into -1 (if you say non zero is -1). The get-property now would return -1, and by no mean 17.21.

About parameters types, it's a question of overloading, or I don't exactly see what you mean?
marcov wrote:How do you make conditional expressions assignable to them? (does a<b return an int value, like in C, or a boolean like in pascal?)
Overload operators. Do I answer correctly?
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: Boolean Data Type in freebasic

Post by caseih »

Tourist Trap wrote:Hello. I have first been surprised not to find boolean in fb. But after a short time I've noticed that if booleans were useful (for me for compatibility with vb.net which I use casually), it was however not necessary to add them as a part of the core language. They rather can be added (at different implementation depth) as standalone UDT. What one may do maybe is offering a full boolean UDT definition with all operators overload, properties, useful extensions, and so on.

The fact is that UDT are very versatile, and once a base defined, can be extended depending on the needs. For instance, I've been using 'Nullable Object' under vb.net, and was able to get nullable booleans, which is a way to get a boolean with 3 values, null, true and false. Nobody would think of such an object to come hardwired in the language.
Having a boolean type in the language seems a bit orthogonal to the Nullable Object idea. In FB's case, a native boolean type could be used to instantiate and access C++ classes directly from FB code, which is one of the stated reasons for doing this in FBC.
Tourist Trap
Posts: 2958
Joined: Jun 02, 2015 16:24

Re: Boolean Data Type in freebasic

Post by Tourist Trap »

caseih wrote:Having a boolean type in the language seems a bit orthogonal to the Nullable Object idea.
It was only an example of how one can extend the language with object programming. In vb.net where booleans are provided, I've extended them to a nullable version, just for a very special case. In an other hand, a language could offer a "hardwired" nullable boolean type but then where is the limit? And my remark was only about this :
Is boolean type worth implementing at core level or just as a kind of arithmetical extension that is best implemented as an user object ?
caseih wrote: In FB's case, a native boolean type could be used to instantiate and access C++ classes directly from FB code, which is one of the stated reasons for doing this in FBC.
That's ok. If the advandage is greater compared to the pain to add this feature at core level, it's good. But since it has not been done yet I had supposed that it should be difficult enough. Because indeed, I love boolean type, and I of course would be happy to get a good implementation whatever the mean.
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Boolean Data Type in freebasic

Post by coderJeff »

Thanks for the responses!

caseih, yes internal storage representation is 0 or 1, what is good for interoperability with g++ libraries. So yes, we are really talking about g++ here since that is the implementation of C++ we are working with. As for operators, if 'a' and 'b' are boolean, then (uop a) returns boolean and (a bop b) returns boolean where 'uop' or 'bop' is a unary operator or binary operator respectively. If one operand is a boolean and the other an integer/float/etc, a compiler warning is generated, but fbc still allows the conversion. Yes, traditionally, in my opinion, BASIC definition of "TRUE" is "not 0" or "-1", and that is exactly what happens when boolean FALSE/TRUE is converted to integer, we get 0/-1.

marcov, I don't know anything about GTK, sorry. A search for "gboolean" type shows me that it is actually a "uint". Is that correct? So it is more like a "C style" boolean type and up to the programmer to make sure gboolean variables only ever hold correct values (FALSE=0, TRUE=1). 32-bit boolean is not impossible, but for now focus is on having the new data type accepted and working with g++ (bool type), which is typically 1 byte only. However, there is 32 bit boolean on the fbc TODO list because gcc=>Darwin would expect that. There is partial (untested) support for other sizes of boolean in the backends. I have not even thought of how fbc might handle 2 or more different sizes of boolean storage locations simultaneously matching headers and object files (libraries).

Tourist Trap, two things regarding your remarks: 1) fbc gains a great deal of usefulness by being able to leverage C libraries made by others, what is only possible because fbc supports an intimate relationship with gcc libraries. With classes (TYPE's) in fbc, it is also _really_ close to being able to make use of g++ libraries except there is no fbc equivalent to the c++ "bool" type. This kind of intimate compatibility is not possible through a fbc-TYPE (UDT) interface only ... which, yes, is an important reason for making 'boolean' a built-in type. 2) Yes, adding a built-in type is not easy! And yes, also worth it. :)
marcov
Posts: 3454
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: Boolean Data Type in freebasic

Post by marcov »

coderJeff wrote: marcov, I don't know anything about GTK, sorry. A search for "gboolean" type shows me that it is actually a "uint". Is that correct?
Afaik gtk(2+) originally had to work with many compilers, some pre C99, so they just didn't want to rely on bool's in their original design. So IMHO it is a boolean type, never mind how it is implemented in assembler or C. Of course you can always trust the load onto the programmer, but that is with any feature.

Anyway, I only mentioned it because it is the reason why FPC went from a one byte boolean to one of each size (1,2,4,8 bytes), and GTK exists for FB.

We already had this size range for "bool" C style booleans. (though in F{C/Delphi that came more from winapi/ActiveX than from C as a language or standard to my knowledge).
However, there is 32 bit boolean on the fbc TODO list because gcc=>Darwin would expect that. There is partial (untested) support for other sizes of boolean in the backends. I have not even thought of how fbc might handle 2 or more different sizes of boolean storage locations simultaneously matching headers and object files (libraries).
Yes 1-byte types is a typical x86 phenomenon. Classic RISC machines dealt badly with non "word" sizes and needed extra and and instructions for it.
Tourist Trap, two things regarding your remarks: 1) fbc gains a great deal of usefulness by being able to leverage C libraries made by others, what is only possible because fbc supports an intimate relationship with gcc libraries. With classes (TYPE's) in fbc, it is also _really_ close to being able to make use of g++ libraries except there is no fbc equivalent to the c++ "bool" type. This kind of intimate compatibility is not possible through a fbc-TYPE (UDT) interface only ...
(E.g. some ABIs might have some difference in passing structs and valuetypes. So the function signature would differ between struct and valuetype)
which, yes, is an important reason for making 'boolean' a built-in type. 2) Yes, adding a built-in type is not easy! And yes, also worth it. :)
I'm all for it, but I of course don't agree with the leverage C/C++. IMHO too much of such a focus on C/C++ reuse hampers developing proper libraries and interfaces, and doesn't set FB as a development system (language+library and general approach of doing things) enough apart from C/C++.
MichaelW
Posts: 3500
Joined: May 16, 2006 22:34
Location: USA

Re: Boolean Data Type in freebasic

Post by MichaelW »

For Windows BOOL is defined as an integer, see Windows Data Types. Considering only code efficiency, using a byte as a logic element in 32/64-bit code makes little sense.
Tourist Trap
Posts: 2958
Joined: Jun 02, 2015 16:24

Re: Boolean Data Type in freebasic

Post by Tourist Trap »

MichaelW wrote:Considering only code efficiency, using a byte as a logic element in 32/64-bit code makes little sense.
You are right, because strictly speaking for booleans, only a bit would have a mathematical sense (storage needed for 0 / 1). So here, if as usual Integer type is the most efficent, it may remain the good choice despite the huge waste of space under 64bits. Moreover for built-in features efficency is of higher importance.
; Machine -----> ASM ---> FB buit-in features-----> FB extended features
; +efficiency concern..............................+hilevel representation concern
marcov wrote:I'm all for it, but I of course don't agree with the leverage C/C++. IMHO too much of such a focus on C/C++ reuse hampers developing proper libraries and interfaces, and doesn't set FB as a development system (language+library and general approach of doing things) enough apart from C/C++.
The questions about this feature are pointing out the lack of language specification. The only obvious constraint and that hopefully will not change is for freebasic to provide at least a dialect where compatibility with QBasic is maintained. For the rest, beginners would find a very pure basic language very attractive, when more experimented people would probably find good to multiply bridges with C/C++. The problem to set the limits to this is all bounded to language specification.
Last edited by Tourist Trap on Jul 23, 2015 9:59, edited 4 times in total.
marcov
Posts: 3454
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: Boolean Data Type in freebasic

Post by marcov »

MichaelW wrote:For Windows BOOL is defined as an integer, see Windows Data Types.
Hardly surpising since winapi predates GTK and thus C99 too.

Moreover Windows NT was set up to run on RISC too, it might come from there.
Considering only code efficiency, using a byte as a logic element in 32/64-bit code makes little sense.
I don't know that any more for current CPUs. The old rule (till core2) was that Intel favoured simple, aligned code, and AMD tightly packed everything. Is a movzbl really slower than a plain mov nowadays?

Windows NT was set up to run on RISC too, it might come from there.
Tourist Trap
Posts: 2958
Joined: Jun 02, 2015 16:24

Re: Boolean Data Type in freebasic

Post by Tourist Trap »

marcov wrote:I don't know that any more for current CPUs. The old rule (till core2) was that Intel favoured simple, aligned code, and AMD tightly packed everything. Is a movzbl really slower than a plain mov nowadays?
From what I've been observing in the hardware section of the forum FB may also be used on many embedded systems, with all types of old small and cheap processors. So maybe efficiency constraint will remain true?
marcov
Posts: 3454
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: Boolean Data Type in freebasic

Post by marcov »

Tourist Trap wrote:
marcov wrote:I don't know that any more for current CPUs. The old rule (till core2) was that Intel favoured simple, aligned code, and AMD tightly packed everything. Is a movzbl really slower than a plain mov nowadays?
From what I've been observing in the hardware section of the forum FB may also be used on many embedded systems, with all types of old small and cheap processors. So maybe efficiency constraint will remain true?
As soon as you go to embedded, bytepacking becomes important again. Of course embedded is a relative term nowadays.

Anyway why it was decided to support the full range of primitive sizes. If you need to support two, you might as well support all four (1,2,4,8 byte). Bitpacking (1 bit), afaik uses "boolean" semantics. (so the sixth 1-bit field packed into an int returns "1" if on, and 0 if not)

The rationale was that as soon as you have two different values in two different architectures, it might find its way into file structures needing the size also on other targets to be able to easily express the structure of the file in an architecture dependent manner.

So have boolean8..64 and map "boolean" in an arch specific way to any of them. Same for BOOL.
Post Reply