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

[munair]

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>

Logical operators do not need a Bool type...

[Ñuño_Martínez]

You forgot something:  Pascal is a high-level language, C is low-level language.  Actually C is a quite thin layer over Assembler (or it was in the good old days).   That's why it didn't had a boolean type until C99: because Assembler doesn't have it, and boolean checking works exactly the same way (zero vs. non-zero).

[Thaddy]

You forgot something:  Pascal is a high-level language, C is low-level language.  Actually C is a quite thin layer over Assembler (or it was in the good old days).   That's why it didn't had a boolean type until C99: because Assembler doesn't have it, and boolean checking works exactly the same way (zero vs. non-zero).

Actually the early versions of C and Pascal are quite similar - C is even partly based on some Pascal design criteria as per Dennis Richie -, so I don't agree.
And a lot of  processors allow for flags (effectively boolean bits) so that is also not correct.
C was designed as a practical language, not an educational language, and as such took shortcuts that never disappeared.
The statement that C - even in its K&R guise -  is a low-level language is plainly not true in comparison to procedural Pascal. These two are evenly matched, with Pascal edging to better readability and maintenance.
The difference only appears with the introduction of Object Pascal and again later C++ that one can speak of high level languages as such. Those introduce quite a distinct level of abstraction.
Both are influenced by Algol.
https://en.wikipedia.org/wiki/C_%28programming_language%29
https://en.wikipedia.org/wiki/Pascal_%28programming_language%29
https://en.wikipedia.org/wiki/Comparison_of_Pascal_and_C

[guest58172]

In C bool is a 1 bit (Yes i mean bit) integer. Pascal Boolean type sucks a bit. Stuff like

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

1. someInteger += Byte(stuff = other);

are syntactically heavier than the C equivalent, where the cast is not required

Code: D  [Select][+][-]

1. someInteger += stuff == other;

I agree with the OP wish, this would be great but also on pointers and reference types (so class and interface

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

1. if someClassInstance then ... ; // equivalent to if if someClassInstance <> nil
2. if somePointer then ... ; // equivalent to if if somePointer <> nil

[Thaddy]

In C bool is 2 bits integer. Pascal Boolean type sucks a bit. Stuff like

Where did you get that from? It is plainly not true.

[munair]

In C a bool and char are the smallest types and occupy both 1 byte of memory. There may be C compilers out there where the bool type is more than 1 byte.

[flowCRANE]

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?

Of course bitwise. The proposal does not concern the change in the behavior of logical and bitwise operators, but quiet conversion if the result of the expression is an integer, not a logical value.

[440bx]

Of course bitwise. The proposal does not concern the change in the behavior of logical and bitwise operators, but quiet conversion if the result of the expression is an integer, not a logical value.

Engkin is right.  There is no "of course" in the decision.  If a language bestows logical properties onto types that are not logical (that is, not real Booleans) then there will be ambiguous cases that must be resolved.

In Engkin's example, if the two variables are integers and the language bestows logical properties onto integers (such as non-zero being true and zero false) then the expression he showed cannot be decided.  That's why C and C++ have distinct logical and bitwise operators (| and || to contend with that case and....  what a nice source of bugs those are... topped with == ... it's stuff like that, that makes you wonder... who in the world came up with this *rap... oh wait..we know who did... chuckle.)

[guest58172]

In C a bool and char are the smallest types and occupy both 1 byte of memory. There may be C compilers out there where the bool type is more than 1 byte.

Yes but for bool only 1 bit over 8 are actually used. (sorry I mean 1 bit integer earlier).

[guest58172]

In C bool is 2 bits integer. Pascal Boolean type sucks a bit. Stuff like

Where did you get that from? It is plainly not true.

Sorry, I meant **1** bit integer.

[flowCRANE]

Engkin is right.  There is no "of course" in the decision.

Well, again.

The operators' behavior will not change — the compiler would still decide on the choice of a logical or bitwise operator based on the context, nothing changes here. The given expression in the conditional statement is always solved until one value is received. This value can be anything — number, boolean, character, record, reference, array etc.

So if the calculated result of the expression is not a typical boolean, then it should be checked if it is ordinal type and if so, convert to boolean (or not and test it just as a number), and if not, return the compilation error.

The overhead of testing the tyle of the final value of the expression in this case must exist, but there is no case where the compiler would not be able to determine whether the implicit conversion is to take place or not. And the operators used in the expression have no meaning here.

If a language bestows logical properties onto types that are not logical (that is, not real Booleans) then there will be ambiguous cases that must be resolved.

False and True values are a human invention and Pascal-specific — for the processor everything is just numbers.

[munair]

Logical values are a human invention — for the processor everything is just numbers.

The processor (computer) is also a human invention. Compilers were invented to make life easier; they translate as they have been programmed. Good compilers indeed make a distinction between logical and bitwise operators. For example:

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

1. ax = 100h
2. al = ax and FFh // bitwise
3. if ax and FFh then // logical

This would make much more sense:

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

1. al = ax & FFh // bitwise
2. if ax and FFh then // logical

[Bart]

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

April fool 

Bart

[flowCRANE]

The processor (computer) is also a human invention.

It was not about this type of invention. 

Good compilers indeed make a distinction between logical and bitwise operators.

I feel that hardly anyone understand the nature of the problem. And the essence of the problem is not just the calculation of expressions, but testing their result (responding to its type and choosing how to test it, do additional steps or not).

April fool 

Even if, I would not mind that such functionality would be applied in Free Pascal (I would definitely use it). But of course it will not happen, as well as inline variable declarations — it is known why.

[440bx]

Well, again.

yes, again you're wrong.  you got the consistency part, that's good.

The operators' behavior will not change — the compiler would still decide on the choice of a logical or bitwise operator based on the context, nothing changes here.

There is plenty that changes.  For instance:

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

1. var
2.   AnInteger = 7;
3.   AnotherInteger = 5;
4.   ..
5.   SomeVar = 1;
6.  
7.   if AnInteger and AnotherInteger = SomeVar then....
8.  

There is no way for the compiler to decide, with context or otherwise, what it should do.  It could interpret that statement as true and true = true which would be true or it could just as well interpret it as a bitwise operation compared to the numeral 1, 111 and 101 = 1 which would be false.  As I stated in the previous post, that's why C and C++ use a different operator, that's what allows those compilers to distinguish between such cases.

So if the calculated result of the expression is not a typical boolean, then it should be checked if it is ordinal type and if so, convert to boolean (or not and test it just as a number), and if not, return the compilation error.

That's a mess.  Any pile of bits, as long as they fit in a CPU register, can be an ordinal.

The overhead of testing the tyle of the final value of the expression in this case must exist, but there is no case where the compiler would not be able to determine whether the implicit conversion is to take place or not. And the operators used in the expression have no meaning here.

Why do you think C and C++ have different operators for logical and binary operations ? they are not Christmas ornaments, they are needed to disambiguate expressions that would otherwise be undecidable.

False and True values are a human invention and Pascal-specific — for the processor everything is just numbers.

The names we choose to give to identify states are a human invention but the states aren't.  The words "green" and "blue" are human "inventions" but the wavelengths they identify (in this case, rather imprecisely) are not.  And, for the record, processors know nothing about numbers, all they know about is two states (which we call true and false). At the circuit level, everything is done with logical operations on two states.