I wish for a better BOOLEAN operation within the IF statement.

[jamie]

Why can't we do this like in C ?
If SomeInteger then.....

I know C is a cryptic syntax which is why most of us are here however, there are some things
here and there that enhances coding..

I know you can cast around a non Boolean type to do this however, like in C, any type that deals with
numbers get accepted as a Boolean operation when testing for 0 or non-zero False or true. At the same time
this same value can be used for INFO as a  number..

 you'll see this a lot in functions in windows where the return type is an integer but the definitions states the
return as being True of false, only because the return value could be 0 or non zero

Take the postmessage for example, it returns a integer but many functions when used specify TRUE or False.

So, taken this into consideration I wish the compiler would know how to handle the IF SOMENUMBER Then.....
operation..

[lucamar]

It's not really a problem of Boolean but a problem with C. In C, there's really no "boolean": it simply interprets integers a certain way. That's why you can have this in C:

Code: C  [Select][+][-]

1. if (a = b = Somefunction) { ... }

Pascal is (way) stronger typed, so a Boolean needs to be boolean, i.e. it must have only two possible values: False or True and it's guaranteed that Succ(False) = True and Pred(True) = False.

Don't be mistaken, Pascal strong-typing is one of its strengths: allowing in Pascal the barbarities you can do in C may look nice at first glance but they (usually) enact a heavy penalty in terms of predictability, readability and maintainability of code.

[..] you'll see this a lot in functions in windows where the return type is an integer but the definitions states the
return as being True of false, only because the return value could be 0 or non zero

Most of Microsoft's code that behave like that is just because pure lazines: if a function doesn't return a definite value, 0 is interpreted as sucess and any other (random) number as failed (or viceversa). From there, they say that the function return a boolean, but they mean it in the C sense: i.e. the function really returns an integer that can be interpreted as a semi-boolean value.

You can see that even in the (very) old BASIC interpreter for the Altair.

[engkin]

I like C in its own code. I don't like to see Pascal getting closer to C.

Introducing "if SOMENUMBER then" will cause problems with code like:

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

1.   if SOMENUMBER1 and SOMENUMBER2 then

Is and here a bitwise or logical operator?

[Leledumbo]

You need typing discipline lesson, which of course is absent in C (but not in further C descendant languages, because they know how important this thing is actually). Don't use Pascal if you want weak typing and believe you can 100% avoid typing errors (that may result in undefined behavior that may be left undetected for years but silently destroys something under the hood).

WinAPI was made with C in mind, because that's what was available at the time of writing. TRUE and FALSE there is a macro for 1 and 0, but you can specify other numbers, or basically anything, as well (undefined behavior) to functions expecting BOOL. With that said, some functions may return true for an integer value other than 1. Pretty shitty IMNSHO, and I wonder what it is that "enhances coding" other than serving lazy typers to kill further maintainers.

Reference: https://docs.microsoft.com/en-us/windows/desktop/learnwin32/windows-coding-conventions

[ASBzone]

Why can't we do this like in C ?
If SomeInteger then.....

Is it really so onerous to type:

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

1. if (SomeInteger <> 0) then ...

[Thaddy]

Is it really so onerous to type:

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

1. if (SomeInteger <> 0) then ...

Or even:

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

1.  if 100.ToBoolean then..

which does the same under the hood.
Imho a lot clearer than the ambiguous and accidental C "syntax".
It belongs to the discoveries that something happens to work in C, not that it is designed to work in C.
(C doesn't have much design, - well, modern C more so than K&R-  and the accidental "features" list is quite long because of that. 
Actually C doesn't even have a true bool unless declared as a typedef enum (C99+) or a #define)

[munair]

There is a difference between zero/non-zero and false/true. Some languages allow for simple testing whether a value is zero or non-zero, like

Code: Text  [Select][+][-]

1. if not value then // if zero
2. if value then //non-zero

The definition of FALSE and TRUE however may be different. It is a general agreement that FALSE is associated with zero. But for TRUE we cannot simply assume non-zero. Some languages insist on -1 while other languages define TRUE as 1:

For instance:

Code: Text  [Select][+][-]

1. const FALSE = 0
2. const TRUE = not FALSE

What is TRUE? Depending on the compiler TRUE could be any non-zero value.

And what if:

Code: Text  [Select][+][-]

1. const TRUE = 0
2. const FALSE = not TRUE

A specific boolean type avoids problems and confusion and also makes debugging easier.

[Thaddy]

@munair
In Pascal a Boolean is mapped to either 0 or 1, a Pascal Bool type is equivalent to a C bool - which only exists from C99, which is really an integer (ordinal)  type where any value other than zero is true and implementation dependent. It differs per C compiler. The latter is not the case for a true Pascal Boolean. All this is in the manual. We gave some examples in the last two posts before yours on how to handle that.

To complicate matters:
const
   true   = 1;
   false = 3;
Is legal pascal syntax, as is:
const
  true   = 'true';
  false = 'false';

That's because true and false are not keywords, but consts that can be overridden. (since 3.0.0 I believe)

[six1]

as a side note it is also possible to use:

var
 b : boolean;
 i: integer
begin
 b:=true;
 i := ord(b); // i = 1

 b:=false;
 i := ord(b); // i = 0
end;

[Thaddy]

as a side note it is also possible to use:

var
 b : boolean;
 i: integer
begin
 b:=true;
 i := ord(b); ' i = 1

 b:=false;
 i := ord(b); ' i = 0
end;

No. Too many syntax errors..... Plz test before posting.

Anyway, consider this:

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

1. {$MODE OBJFPC}{$H+}
2. var
3.  b : boolean;
4.  bl: longbool; // which is a C bool32
5.  i: integer;
6. begin
7.  b:=true;
8.  i := ord(b); // i = 1
9.  writeln(i);
10.  b:=false;
11.  i := ord(b); // i = 0
12.  writeln(i);
13.  bl := false; // i := 0
14.  i:=ord(bl);
15.  writeln(i);
16.  bl := not  b;
17.  i := ord(bl); //i =  -1
18.  writeln(i);
19. end.

Explanation:
Without an actual value, the not operator turns it in a series of $F's which will become negative 1.
With an actual value there's the reverse operation with zero, so 100.ToBoolean becomes true too.

[six1]

Yes you are right. It was only a matter of principle.
Replace the apostrophe with slashes...

[munair]

Yes you are right. It was only a matter of principle.
Replace the apostrophe with slashes...

And add a semicolon...

[Thaddy]

Yes you are right. It was only a matter of principle.
Replace the apostrophe with slashes...

As per my example: Ord() isn't necessarily a good thing here. The ord() of a C type boolean is *before* zero.

[Peter H]

In classic C there are the operators  == ! && || ^^ and the result is always true or false which is normally mapped to the integer values 0 and 1.

So there are strictly boolean operators and this is why classic C does not need a boolean type.
Boolean type in C is only for clarity and portability.

If  =, not, and, or, exor, where strictly boolean operators, then implicit type conversion of integer to boolean would be thinkable in theory.

But, so far I know, it was Borland, who made these operators polymorphic so that they can do also arithmetic conversions.

So, if a is 1234 then the construct
IF NOT a THEN ..... would be undefined if a could automatically propagate to boolean.

So new compiler directives would be needed to implement this idea. 

[Thaddy]

In classic C there are the operators  == ! && || ^^ and the result is always true or false which is normally mapped to the integer values 0 and 1.

Classic C has no Bool type..... <sigh> And it is mapped according to compilers. E.g. GNU C and MS C map to a negative integer for TRUE if no default value is given.
Only pascal Boolean (not longbool and family)  map to 0 and positive 1 in all cases.
Note that 1 is a valid NOT zero, but that's not the mapping you describe...That's plain wrong.
See https://www.freepascal.org/docs-html/current/ref/refsu4.html and any C99+ documentation on bool.

And this one (plz read it at least three! times because otherwise you will stay confused): https://en.wikipedia.org/wiki/Boolean_data_type#C,_C++,_Objective-C,_AWK
That seems to suggest 0..1 but describes otherwise.