Why is a Boolean expression (with side effects) not enough as a statement?

Question

function A: Boolean;
function B: Boolean;

I (accidently) wrote this:

A or B;

Instead of that:

if not A then
  B;

The compiler rejects the first form, I am curious why?

With short circuit evaluation they would both do the same thing, would they not?

Clarification: I was wondering why the language was not designed to allow my expression as a statement.

Canorous

Actually, I'm glad that this is not allowed because it is IMHO not at all readable. Interesting question though. – Houseboy

Because Delphi is not fractal of PHP yet. – Counterweight

Answer 1

Simply, because the compiler is expecting a statement and the expression that you have provided is not a statement.

Consult the documentation and you will find a list of valid statements. Your expression cannot be found in that list.

You asked in the (now deleted) comments why the language designers elected not to make such an expression count as a statement. But that question implies purpose where there may have been none. It's perfectly plausible that the designers did not decide not to do this. Rather they never considering doing it in the first place. Languages are generally designed to solve specific problems. It's perfectly plausible that the designers simply never considered treating such expressions as statements.

Chastise

Answer 2

The first is an expression. Expressions are evaluated. Expressions have no visible side effects (like read or write a variable). Both operands of the expression are functions and those can have side effects, but in order to have side effects, a statement must be executed.

The second is a statement. It compares the result of an expression and based on the evaluation calls another function.

The confusing part, is that in this case, Delphi allows us to disregard the result of a function and execute it as a function. So you expect the same for A or B. But that is not allowed. Which is great because the behaviour is ambiguous. For example, if yo have lazy evaluation enabled. And A evaluates to true, is B called yes or no.

Johanajohanan

It's worth making the point that you can just the same construct a valid statement that will also ambiguously execute B depending on lazy evaluation. if (A or B) then... etc – Carpel

"Expressions have no visible side effects (like read or write a variable)." Writing a variable is a visible side effect! Not to mention that function calls are also expressions, which can of course have side effects. – Consumptive

Answer 3

The first form is an expression which evaluates to a Boolean value, not a statement.

Subfusc

Answer 4

At its heart, Delphi is Pascal. The Pascal language was designed by Nicklaus Wirth and published in 1968. My copy of the User Manual and Report is from 1978. It was designed with two purposes in mind, as a teaching language and as one that was easy to implement on any given machine. In this he was spectacularly successful.

Wirth was intimately familiar with other languages of the time (including Fortran, Cobol and particularly Algol) and made a series of careful choices with particular purposes in mind. In particular, he carefully separated the concept of 'actions' from 'values'. The 'actions' in Pascal are the statements in the language, including procedure call. The 'values' include function calls. In this and some other respects the language is quite similar to Algol.

The syntax for declaring and using actions and values are carefully kept quite separate. The language and the libraries provided with it do not in general have 'side effects' as such. Procedures do things and expressions calculate values. For example, 'read' is a procedure, not a function, because it retrieves a value and advances through the file, but 'eof' is a function.

The mass market version of Pascal was created by Borland in the mid 1980s and successively became Turbo Pascal for Windows and then Delphi. The language has changed a lot and not all of it is as pure as Wirth designed it. This is one feature that has survived.

Incidentally, Pascal did not have short-circuit evaluation. It had heap memory and sets, but no objects. They came later.

Bordelon