Short circuit evaluation: yes or no?

[spotlessmind1975]

Hi to everyone!

Someone asked if ugBASIC supports short circuit evaluation.

On Wikipedia there is a complete explanation.

In a short, the following argument in a boolean expression is executed or evaluated only if the first argument does not suffice to determine the value of the expression. I.e. if we have an AND operator, and the first term is false, we do not need to calculate the second term.

From my point of view, this is a very thorny discussion.

Conceptually, short circuit evaluation is a functionality introduced by some medium-level languages, such as C. The reason why it was introduced is linked to the fact that it allows obtaining notable optimizations, at the cost of avoiding the execution of specific functions. The problem with introducing this type of optimization is that the functions that you avoid performing could have "side effects", and in ugBASIC, side effects are quite common, due to the fact that it is a stackless language.

What is your opinion?

[wysardry]

I'm not 100% sure what you mean by "side effects".

I can see it might cause issues if there is an error in the code that doesn't get executed and the compiler doesn't notice it because it hasn't read that part. However, I would expect the compiler to do at least some checks (such as syntax validity) on all the code during the first pass.

If I was writing a BASIC compiler, I would check the ANSI standard documentation or find out how Pascal handles this (as Pascal is probably the most similar language to BASIC). That way, there are likely to be existing solutions to any problems the choice may cause.

I wouldn't take any notice of how C does this, as the language has so little in common with BASIC.

[ldir_hector]

I am not sure about Ansi Pascal, but I know that in Turbo Pascal "AND" and "OR" are short circuited as in C.

So you could write something like :

WHILE x <> 0 AND 1/X > 0.5
BEGIN

END

That's a quite common way to write code for at least the last 20 years !

Anyhow, the most important thing is to keep consistent. If you already have an important amount of code written with AND and OR without this short circuit, their code may keep a correct syntax and work correctly but in the future, they would appear weird to the readers who code with Short circuit in mind.

[spotlessmind1975]

Hi wysardry!

I'm not 100% sure what you mean by "side effects".

Ok, so, let's imagine we're writing a role-playing game. In this game there is a function, which is called isHungry. This function checks whether the player is hungry ( ) and, if he/she is hungry and there is enough food in the backpack he carries with him/her, the player consumes it and returns FALSE. However, if the player is hungry but has no food, it returns TRUE. If the player is not hungry, returns FALSE.

Now suppose we have the following condition:

Code: Select all

IF isInDanger AND NOT isHungry[ ] THEN
    runAway[ ]
ENDIF

If short circuits are not in effect, the system will make the player run away if he/she is in danger and not hungry (either because the player actually is not hungry, or because he/she was able to eat). If short circuits are in effect, the player who is not in danger will never eat!

In this case, the "side effect" is food consumption.

That way, there are likely to be existing solutions to any problems the choice may cause.

The "side effects" problem is present also in Pascal, as well.

That's a quite common way to write code for at least the last 20 years !

Yes indeed you are right. One of the most widespread conventions is precisely that of exploiting short circuits as a synthetic way of writing code in defensive programming.

Anyhow, the most important thing is to keep consistent. If you already have an important amount of code written with AND and OR without this short circuit, their code may keep a correct syntax and work correctly but in the future, they would appear weird to the readers who code with Short circuit in mind.

Generally speaking, short circuiting is not something that enters very easily into the mind of the programmer writing an algorithm. Let's say that, if anything, the opposite is true. In the sense that one notices, by running a program perhaps with a step-by-step debugger, that the program excludes one of the conditions and comes to the conclusion that the short circuit is operating. Like: wow, that's right, but who knows!

[wysardry]

Ok, so, let's imagine we're writing a role-playing game. In this game there is a function, which is called isHungry. This function checks whether the player is hungry ( ) and, if he/she is hungry and there is enough food in the backpack he carries with him/her, the player consumes it and returns FALSE. However, if the player is hungry but has no food, it returns TRUE. If the player is not hungry, returns FALSE.

Now suppose we have the following condition:

Code: Select all

IF isInDanger AND NOT isHungry[ ] THEN
    runAway[ ]
ENDIF

If short circuits are not in effect, the system will make the player run away if he/she is in danger and not hungry (either because the player actually is not hungry, or because he/she was able to eat). If short circuits are in effect, the player who is not in danger will never eat!

In this case, the "side effect" is food consumption.

Hmm. I'm not sure I like the idea of using a function within an IF statement in the first place, because I've always used them to check the current state of something before possibly changing it rather than trying to do both at once.

To me, it seems it would make it much harder to keep on top of potential bugs.

Would it be a lot of extra work to add an option to enable or disable this feature if you did add it?

[spotlessmind1975]

Hmm. I'm not sure I like the idea of using a function within an IF statement in the first place, because I've always used them to check the current state of something before possibly changing it rather than trying to do both at once.

In reality it is not that strange: in fact, it is the basis of functional programming. Think, however, about functions for accessing files, and reading/writing data: some of these functions change the internal state of data structures when you call them, even if you aren't actually aware of it. Even then, the use of "short circuits" can alter the behavior of the software.

Would it be a lot of extra work to add an option to enable or disable this feature if you did add it?

To tell the truth, yes, I think there is quite a bit of extra work. The point is that, in ugBASIC, execution only happens after compilation. So short circuiting is equivalent to "not compiling" specific parts of the software. These are structural decisions, which I'm not sure it's possible to leave to the programmes, on behave of one specific option.

[TRS-Eric]

Interestingly, some languages have a different logical operator to avoid short circuiting. In java, and probably most others, the AND operator is & and if you use two && signs, one gets a short circuit AND.

If one has to choose, and I think choosing one option is probably good in a BASIC language, I would choose not to short circuit. We can simply use nesting instead.