Why a draft task?

A comment in here (look for shortcutting), thought that the task would most likely not be written in a neutral manner. I've tried to write a task that allows each language, whether it has short-circuit evaluation or not, to solve the problem idiomatically.
I saw the comments on the Icon solution, for example, which makes me think that the task could soon lose the draft status? --Paddy3118 23:59, 24 July 2010 (UTC)

I removed the draft status as the examples seem to cope (another example is Pascal where some compilers have it and some do not).

Error in task?

The problem states:

  x = a(i) and b(j)
  y = a(j) or  b(j)

But the only example is written as:

  x = a(i) and b(j)
  y = a(i) or  b(j)

Either the definition of the first example is wrong. I'm guessing the task description but ... --Dgamey 17:50, 24 July 2010 (UTC)

You are right of course. Hopefully fixed now, thanks. --Paddy3118 23:43, 24 July 2010 (UTC)

Control structure?

I would be inclined to add the control structure tag to this task. Lisp was one of my early languages to learn, and I always though of short-circuit and and or as control structures. (Of course, as I later learned, many concepts that seem natural and intuitive in Lisp are viewed as insanity by the mainstream imperative programming world....) Anyone else have feelings about adding or not adding the control structure tag? —Sonia 17:18, 20 April 2011 (UTC)


It was used as such for a long time in Python too. value = condition and x or y was used until later syntax additions allowed that to be expressed as value = x if condition else y. So I can see your point. --Paddy3118 17:47, 20 April 2011 (UTC)
In my opinion, short-circuit evaluation is a form of flow of control in any language with side effects. (And, in languages without side effects, flow of control is not a meaningful concept -- there, it's just a question of which results get used, but that should not matter here.) --Rdm 17:44, 20 April 2011 (UTC)
+1 —Ruud 19:17, 20 April 2011 (UTC)

Compiler optimisations?

A variant of this issue arises when the second part of an expression might cause a disaster such as division by zero or indexing out of bounds, as in

while i > 0 and A(i) etc. do i:=i - 1;

where an attempt at A(0) would be improper. The first test protects the second against evaluation only with short-circuiting. A compiler might generate code that always evaluates both parts, or, consistently short-circuits, or, short-circuits only if the first part is a certain sort of expression, such as a boolean variable but not if a function...


Text moved as unclea if it describes fully compliant compiler - If language states short-circuit then compiler should be compliant. --Paddy3118 (talk) 16:07, 28 April 2015 (UTC)
Return to "Short-circuit evaluation" page.