Re: Why doesn't foreach return a value

On Jan 30, 8:47 am, Darren New <d...@xxxxxxxxxx> wrote:
tom.rmadilo wrote:
Foreach actually never 'goes away', so how could it return?

Of course it returns, like every other command does. (Well, except
infinite loops.) What do you mean "goes away"?

Call 'return' inside a loop and you will discover the difference
between a function/proc and a foreach loop. Foreach doesn't 'go away',
because the foreach body is executed in the current context.


Is it called as a function, or is is simply used in the current flow of code?

It's called as a function, as is every other command in Tcl, including
proc, while, if, and so on.

Yes, in Tcl, but this is a syntactic feature of the language. I'm
talking about the purpose of the call. Is the purpose to return a
value, or to perform some operation, or both? If you don't make these
distinctions, but only compare the syntactic similarities, you will
have difficulty accounting for other commands like [catch], [return -
code return], [error], etc.

In this case, if you store the result of the function call, I assume
you want the value, otherwise you don't.

I doubt you will find any logical support for anything in particular.

Returning either the second argument or the final value of the first
argument or the length of the second argument might all be useful. But
these are all things that are trivial to get in other ways.


The final values are already available:

% foreach a {b c d} {break}
% puts $a
b


If "break" was changed to take an argument, returning the value passed
to break might be interesting. But again, I expect this can already be
done with clever use of [return].

You don't usually [return] from a loop. (You can, but the [return] is
applied to the context, not the loop boundary.

The problem of building in some additional meta-data is that it would
then be required to exist for every loop. How will this information be
accessed? The commands [break] and [continue] are part of the control
code, so you can do whatever you want before you call them. There is
no 'logical' good thing to do here, there are many possible things. It
also complicates code analysis, since the developer has to figure out
'what' is being returned.

The most obviously useful information would be some kind of metadata
which documents what happened, mostly for the case of continuing,

Continuing what? The loop runs until it exits, at which point you don't
continue it.


[continue] at the next iteration of the loop by skipping everything
following the [continue] command.

maybe what state the loop was in upon exit.

What do you mean? What state do you not get when you exit?

That is pretty much my point. If you break up a paragraph of my
statements and ask a question for each one, you miss the larger point.
There is not logical chunk of meta-data to track (like maybe exactly
how many iterations were completed, which if any iterations used
[continue], etc.) These are all useful in some situations, but not
generally. Contrast this with [regexp], where the return is a boolean.
It can also set matches if variable names are supplied. It isn't
necessary to return a boolean to find out if you were successful, but
it is obviously useful. There is nothing obviously useful with a
return value for foreach/for/while loops. In general the intent of the
code would be obscured by this type of thing, not even mentioning the
ugliness of the code:

set loop_result [foreach num $numbers {
puts "Num = $num"
}]

.

Quantcast