Unwind functions don't propagate from WHILE condition block

[Siskin-Bot]

Submitted by: BrianH

The unwind functions: RETURN, EXIT, BREAK, CONTINUE, THROW.

The unwinding process doesn't propagate from within the WHILE condition block because WHILE doesn't return the unwind values from there (or any values for that matter). If WHILE could check for unwind values returned from the condition block then it could act on BREAK and CONTINUE, or return the rest from the function so they can propagate. As it is now in R3, WHILE treats the unwind value like an untriggered error! and considers it true, which often leads to an endless loop.

This is related to bug #1509, but that refers to function argument processing by DO, while this refers to WHILE.

Note that the behavior of R2 should not be emulated: It is also in error, but a different error.

>> do does [while [return 'good] [print 'bad]]
bad
bad
; ... in an endless loop
>> do does [while [return 'good] [return 'bad]]
== bad  ; should be good

---

^{Imported from: CureCode [ Version: alpha 97 Type: Bug Platform: All Category: Error Handling Reproduce: Always Fixed-in:r3 master ]
Imported from: metaeducation#1519}

Comments:

Rebolbot commented on Nov 2, 2010:

Submitted by: Ladislav

in the core-tests suite

---

Rebolbot commented on Nov 11, 2010:

Submitted by: BrianH

Weird: I was expecting QUIT and HALT to be caught by this as well, but they aren't, and not by #1760 either.

---

Rebolbot commented on Jan 24, 2013:

Submitted by: BrianH

Expanded the tests for this in core-tests. As of alpha 111, BREAK and CONTINUE apparently work in the condition block, but the other unwinds aren't passed through. Doesn't work in R2 either, but it's a bug there too.

---

Rebolbot mentioned this issue on Jan 12, 2016:
RECOVER native function or CATCH/recover option
WORDS-OF TRY [BREAK] crashes
Unwind functions don't propagate from REDUCE

---

Rebolbot added Type.bug and Test.written on Jan 12, 2016

---

Hostilefork added on Jan 24, 2018

---

Hostilefork commented on Mar 23, 2018:

I don't think the highest value for CONTINUE or BREAK in a condition of a WHILE is to have that WHILE process it. Reasons:

1. The condition can already control the loop... if it evaluates to TRUE then the body will run again, if FALSE it won't run.

2. CONTINUE is semantically ambiguous as to whether the condition should be run again, or if it should go directly to the body. Pursuant to point 1, the more "expressive" choice would be to run the condition again...since that's something that TRUE wouldn't do (it would just run the body). But it's rather confusing.

A recent change to Red made it illegal to use BREAK or CONTINUE in a WHILE's condition. That is probably clearest, in terms of "principle of least surprise", since it keeps one from having to worry over the semantics of whether continue runs the condition again or not.

But what seems most useful is just to not consider the condition to be a slot where BREAK or CONTINUE would be handled any differently. So it would be assumed to refer to some enclosing loop construct. This unambiguous interpretation is based on the idea that a while's body is a kind of context for a new BREAK or CONTINUE to arise...the condition is separate. So that's the strategy used in Ren-C.

---

[Oldes]

Current behaviour is:

>> do does [while [return 'good] [print 'bad]]
== good