Re: Why doesn't foreach return a value

On Thu, 31 Jan 2008 00:46:39 -0800 (PST),
suchenwi <richard.suchenwirth-bauersachs@xxxxxxxxxxx> wrote:

There is indeed one logical gotcha for the "return value" of break/
continue:
foreach i {1 2 3} {set a [break b]}
The assignment to a will not take place, because the loop body is left
before. So who will receive the "b" value? One could fantasize that it
ends up as foreach's return value (and similarly for [for] and
[while]):
set status [foreach i {1 2 3} {if $x {break b}}]
If x is non-zero, status would be "b"; else "" as usual.

The key is that you're actually returning two distinct values.

There's a "return code", which is a simple numeric value passed back at
the C level (with no actual real storage allocated, it's usually just
left sitting in a register or on a standard location within every
stack frame), with the usual values TCL_OK, TCL_ERROR, TCL_RETURN,
TCL_BREAK, and TCL_CONTINUE. When a [proc] finishes normally, it drops
back a TCL_OK to the caller. Other commands like [return], [break],
and friends, drop back a different number.

The "result value", which can be any TCL value, is actually stored
independently within the interpreter, and in fact, has special commands
to set/get it at the C level. This value is also modified by the likes
of [return], but as shown, left untouched by the present [break] and
[continue] functions.

In brief, as I understand these things, this value is explicitly
REMOVED by [foreach] under a "return code" of TCL_BREAK or
TCL_CONTINUE. Most (all?) other return codes (TCL_OK, TCL_ERROR,
TCL_RETURN, and any other undefined return code) simply leave it
untouched. In the special case of TCL_ERROR, extra information is
added to the ::errorInfo variable as well. It could be the code
invoked to evaluate the loop body, which dumps the interpreter result,
but without looking at the TCL source (which my head isn't really
sufficiently clear to be doing right now), I can't say for sure which.
But considering [if] and [proc] retain the last value, I'd say it's
[foreach] doing it itself.

Basically, all this boils down to, is removing the explicit flushing of
the interpreters result value for the TCL_BREAK and TCL_CONTINUE cases,
and setting it in the [break] and [continue] commands themselveds. Just
let it flow on though, like [if] and [proc] do. You could also just let
it retain its present value in the case of the loop body completing
naturally. I'm not sure if any care needs to be applied around
variable traces, I'm guessing they clean up after themselves and/or
wouldn't be an issue anyhow.


For [while] and [for], the deal would be exactly the same, except that
one extra step is required to return the last iteration result. You'd
need to grab the result if the body completes naturally, and set it as
the loops result value after failing the condition (which would have
just set a new result value). Though there is some case for keeping
the condition result value instead (as opposed to [if] and (proposed)
[foreach] which return the result of body evaluation). So for those
two, it'd probably be best to forget about fiddling with saving the
body result, and just leave the interpreters result value as-is, just
as with [foreach]. But that's a separate topic.


Fredderic
.