Boolean type

[440bx]

Really? I have not seen that proof.

No problem...

Code: Pascal  [Select][+][-]

1. program _BooleanType;
2.   { proof that boolean = bytebool                                             }
3.  
4.   { there is NO boolean type in FPC                                           }
5.  
6. var
7.   i          : integer;
8.  
9. begin
10.   { what an amazing coincidence that every value from 1 to 255 prints TRUE,   }
11.   { surprisingly consistent for something that is supposedly "undefined"      }
12.  
13.   for i := low(byte) to high(byte) do
14.   begin
15.     { no warning about typecasting an integer into a boolean.  Not even a     }
16.     { hint about possible loss of range/precision or whatever you want to     }
17.     { call it.                                                                }
18.  
19.     writeln('boolean(', i:3, ') : ', boolean(i):5);
20.   end;
21.  
22.   writeln;
23.  
24.   { let's do some more "undefined territory" for fun                          }
25.  
26.   for i := low(byte) * 2 to high(byte) * 3 do
27.   begin
28.     { no warning about typecasting an integer into a boolean.  Not even a     }
29.     { hint about possible loss of range/precision or whatever you want to     }
30.     { it.                                                                     }
31.  
32.     writeln('boolean(', i:3, ') : ', boolean(i):5, ' byte(', i:3, ') : ', byte(i));
33.   end;
34.  
35.  
36.   readln;
37. end.            
38.  

but, of course, it's pure coincidence that any value that ends up being a zero byte is considered FALSE while any other value is TRUE.  Amazing how "undefined territory" is so consistent.  Heck!, undefined territory is more consistent than the way FPC handles typecasting.

Any type that implements more than 2 states is NOT, by definition, a boolean type.  It's something else, most likely a C BOOL but most definitely not a boolean.  FPC's boolean is a boolean like the Pope is a Russian astronaut. 

[Zoran]

Wrong.

It is true only if it equals 1, false only when it equals zero, all other values are undefined.

You believe that ? ... I got a really good deal for you on a bridge in NY...

Hm... I have no reason not to believe that Boolean is implemented according to what is documented. If you can show it is not, please do.
What is documented is - a byte of value 0 is treated as False, byte of value 1 is treated as True. All other 254 values are treated anyhow. So please report if you encounter that the implementation does not follow this specification.

It has already been shown that FPC will consider any value other than 0 to be TRUE for a boolean.  That's not undefined territory, that's a FACT.  That's been proved, your wishful thinking doesn't change reality.

Do you expect that a prng should be engaged to provide random output for undefined values, to persuade you that they are undefined?

If it is implemented somewhere that it treats zero as False, and all other values as 1, it is obviously in line with what's documented - zero is false, one is true, anything else - whatever.
Of course, you must never rely on what you get once for any undefined situation. In next fpc version, or even in current, but for different target, you can get different value in same situation.

You and/or anyone else for that matter, can claim Santa Claus exists but, it doesn't make it that way.

The malicious claims about Santa Claus will get you no good. Expect nothing for next Christmas.

[440bx]

Hm... I have no reason not to believe that Boolean is implemented according to what is documented.

Of course not.  Nothing other than the program posted above.

Why settle for facts when you can simply claim whatever you'd like reality to be ?... (sadly, that's becoming too common)

The documentation states that when it comes to boolean, only 1 is TRUE.  That is NOT reality.  Any value other than 0 is considered TRUE and, supposedly that's only the case for BOOL types not boolean.

You need to read the documentation again.

[Zoran]

Is this conversion behaviour documented anywhere? Not a word about it in https://www.freepascal.org/docs-html/ref/refse85.html#x147-17100012.5 page.

operator overloading ?

What about operator overloading?
With that, among other things, you get the assignment compatibility, and as expected, the integer value converts to Double when assigning.

So, if you want that, you simply use:

Code: [Select]

DoubleVar := Int64Var;But if you explicitly use type casting:

Code: [Select]

DoubleVar := Double(Int64Var);then you obviously don't expect to get the same as with simple direct assignment.

[Zoran]

Hm... I have no reason not to believe that Boolean is implemented according to what is documented.

Of course not.  Nothing other than the program posted above.

All I could see from that programme is that you actually expect a prng engaged to get you random values, in order to accept the fact that the value is undefined. 

You need to read the documentation again.

I wonder what new I will see there...
But...

Free Pascal supports the Boolean type, with its two predefined possible values True and False. These are the only two values that can be assigned to a Boolean type. Of course, any expression that resolves to a boolean value, can also be assigned to a boolean type.

there seems to be nothing new...

[ASerge]

It has already been shown that FPC will consider any value other than 0 to be TRUE for a boolean.

Not always.

Code: Pascal  [Select][+][-]

1. {$MODE OBJFPC}
2. {$IFDEF WINDOWS}
3.   {$APPTYPE CONSOLE}
4. {$ENDIF}
5.  
6. procedure PrintBoolean(V: Boolean);
7. const
8.   CNames: array[0..2] of string = ('False', 'True', 'Error');
9. begin
10.   Writeln(CNames[Ord(V)]);
11. end;
12.  
13. var
14.   VBool: Boolean;
15.   VByte: Byte = 2;
16. begin
17.   VBool := Boolean(VByte); // Only bad programmers do that
18.   PrintBoolean(VBool); // Error
19.   VBool := VByte <> 0; // The right programmers do this
20.   PrintBoolean(VBool); // True
21.   Readln;
22. end.

About typecast.
Personally, I would prefer that the compiler returns an error when typecast if the size (sizeof) of the type and the value are different. Otherwise, nothing. I explicitly specified the typecast, why else warn about it.

In general, typecast should be avoided, as it violates the strictness of the language.

Bad style	Good style
Boolean(IntVal)	IntVal <> 0
Integer(BoolVal)	Ord(BoolVal)
Float(IntVal)	IntVal + 0.0

[BeniBela]

FPC's boolean is a boolean like the Pope is a Russian astronaut.

is that true?

at the moment there is no Pope

for something that does not exist everything is true.  the Pope is a Russian astronaut. and  the Pope is not a Russian astronaut.

[TRon]

But if you explicitly use type casting:

Code: [Select]

DoubleVar := Double(Int64Var);then you obviously don't expect to get the same as with simple direct assignment.

Explicit overloading, see also here.

That global operators on system types are not allowed is an implementation detail (and one for good reason)

for something that does not exist everything is true.  the Pope is a Russian astronaut. and  the Pope is not a Russian astronaut.

a qubit 

[Zoran]

Explicit overloading, see also here.

Ah, yes, there it is documented:

When doing an explicit typecast, the compiler will attempt an implicit conversion if an assignment operator is present.

So, the assignment will be used when typecasting.

And then, below:

However, an Explicit operator can be defined, and then it will be used instead when the compiler encounters a typecast.

I have missed these things.
Not that I like this... but now I know! 

Thanks a lot.

[Martin_fr]

Really? I have not seen that proof.

No problem...

Code: Pascal  [Select][+][-]

1.   { what an amazing coincidence that every value from 1 to 255 prints TRUE,   }
2.   { surprisingly consistent for something that is supposedly "undefined"      }
3.  

Why uprising?  Undefined is not necessarily random.

What you demonstrate is undefined behaviour. Even if it is predictable under the given circumstances.

[TRon]

I have missed these things.

Glad I could be of help (however slightly)

Not that I like this... but now I know! 

It is another reason that renders this topic moot. It allows for the user to design its own type behaving exactly the way as user intended. Wish to create a boolean that is stored as text and can be assign as text , f.e. "PLEASEMAKETHISBOOLEANTRUE" the only accepted string to set it to true as possible implementation ? However weird, it is possible to do so.

[440bx]

I didn't know the Pope had gone the way of the boolean type in FPC.    May he rest in peace.

Let's review some "creative" code:

Code: Pascal  [Select][+][-]

1.  
2. {$MODE OBJFPC}
3. {$IFDEF WINDOWS}
4.   {$APPTYPE CONSOLE}
5. {$ENDIF}
6.  
7. procedure PrintBoolean(V: Boolean);
8. const
9.   { the correct definition.  if the parameter is a boolean then the index     }
10.   { should also be a boolean. booleans can only have 2 values, they are 0 and }
11.   { 1.  That's it.                                                            }
12.  
13.   { just like in a byte, the values can only be 0 through 255. cannot put 256 }
14.   { in a byte.  The same thing applies to a boolean, can't put 2, 3... etc in }
15.   { a boolean.                                                                }
16.  
17.   { you can put it in a BOOL but, a BOOL is NOT a boolean.                    }
18.  
19.   CNames: array[boolean] of string = ('False', 'True');
20.  
21.   { only bad programmers do that                                              }
22.   { vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv          }
23.  
24.   CNamesOriginal : array[0..2] of string = ('False', 'True', 'Error');
25.  
26.   { and why should there be 3 values for a boolean ? a boolean is supposed to }
27.   { have only 2 values.   What happens if the boolean value is 75 instead of  }
28.   { 2 as you conveniently chose ?                                             }
29.  
30. begin
31.   { only bad programmers would ord(V) particularly without doing any range    }
32.   { checking.                                                                 }
33.  
34.   Writeln(CNames[V]);
35. end;
36.  
37. var
38.   VBool: Boolean;
39.   VByte: Byte = 2;
40. begin
41.   { your program proves that FPC isn't considering a boolean variable as being}
42.   { either TRUE or FALSE. It considers it a byte because it is using the      }
43.   { value 2 to index in the array and a boolean cannot have the value 2, only }
44.   { 0 and 1                                                                   }
45.  
46.   { there are plenty of ways the value of a boolean variable can be corrupted }
47.   { it is not only a result of bad programming                                }
48.  
49.   VBool := Boolean(VByte);  { the value of VByte could be corrupted for a     }
50.                             { number of reasons.                              }
51.  
52.   { FPC is using a boolean as if it were an byte index.  that's an atrocity   }
53.   { a boolean isn't a byte.                                                   }
54.  
55.   PrintBoolean(VBool);      { fails to print anything                         }
56.  
57.   Readln;
58. end.                      
59.  

The original code proves that FPC isn't treating the boolean parameter as a boolean but as a byte value.  This is obvious because a boolean can only have the values 0 and 1, therefore it could never index the "error" string.

That program proves (again!) that, as far as FPC is concerned, a boolean is just a byte.  The same code can be used to show that depending on how you code the test, you can make the result to be TRUE or FALSE.  Take your pick.  So much for mathematical correctness.

if FPC had a correct implementation of the boolean type then, the PrintBoolean function would always output something because a bit is either 0 or 1 which would always cause a string from the array to be selected (instead of being "magically" out of range.)

Yet, another proof that FPC does NOT implement the boolean type.

[LV]

Code: Pascal  [Select][+][-]

1. program Project1;
2.  
3. {$mode ObjFpc}
4. {$R+}
5.  
6. type
7.   TZeroOne = 0..1;
8.  
9.  
10. var
11.   B1, B2, B3, B4: boolean;
12.  
13. function boolean_(i: TZeroOne): boolean;
14. begin
15.   if i = 0 then result := false
16.   else result := true;
17. end;
18.  
19. begin
20.   B1 := boolean_(0);
21.   B2 := boolean_(1);
22.   B3 := boolean_(1);
23.   //B4 := boolean_(2);  // project1.lpr(23,19) Error: range check error
24.                       // while evaluating constants (2 must be between 0 and 1)
25.  
26.   writeln(B1);        // Output: FALSE
27.   writeln(B2);        // Output: TRUE
28.   writeln(B3);        // Output: TRUE
29.   writeln(B1 and B2); // Output: FALSE
30.   writeln(B2 and B3); // Output: TRUE
31.  
32.   writeln( B1 = B2); // Output: FALSE
33.   writeln( B3 = B2); // Output: TRUE
34.  
35.   readln;
36. end.
37.  

[Martin_fr]

The original code proves that FPC isn't treating the boolean parameter as a boolean but as a byte value.  This is obvious because a boolean can only have the values 0 and 1, therefore it could never index the "error" string.

What exactly do you try to tell....

Boolean vs Byte (or any other storage) is not a conflict.

Using the bit patterns 00000000 and 00000001 in a Byte is merely a matter of representation. Not of how the logic works.

If I put 0 and 1 on a paper, how round does the zero has to be before what I wrote is no longer boolean?

There are 2 states (as you stated more than twice / pun intended). And those 2 states can be represented in a byte (or word or dword or 256bit container or a page of 1024 bytes ....).

And as long as you do use the container with only boolean operation (store either true or false) only those 2 states are there. So that is correct.

And by the very means of boolean logic itself, if the compiler test for one of the 2 states, and it is not that state, then it is the other.
In fact it only needs to test any one part from which it can tell the difference.
If on a paper the terms True/False are used, the all I (as reader) need to do is to check if it starts with a "T". From that I can tell what it is.


If you use typecasts with data that does not match the known representations, then the container is no longer for boolean use (you started using it for something else). And any attempt to use it as if it were boolean will not have a defined outcome.

But if you don't change its usage, then it will behave according to the boolean rules.

[Zoran]

I have missed these things.

Glad I could be of help (however slightly)

Not so slightly. I've been using this language for decades and it's been a long time since I became too confident, at least with the constructs which I use regularly, and I do use type casting. It's rather strange I haven't had problems.

Not that I like this... but now I know! 

It is another reason that renders this topic moot. It allows for the user to design its own type behaving exactly the way as user intended. Wish to create a boolean that is stored as text and can be assign as text , f.e. "PLEASEMAKETHISBOOLEANTRUE" the only accepted string to set it to true as possible implementation ? However weird, it is possible to do so.

I know that assignment behaviour can be defined and fine tuned with operator overloading, although I've never been interested in using this feature.

But I totally missed that it affects explicit cast.

I have never been attracted by operator overloading feature, though. To me it has always appeared overrated - having a method with an expressive long name has always looked like a better option than overloading an operator.