| tom.rmadilo 2008-01-31, 7:49 pm |
| On Jan 31, 8:31 am, Joe English <jengl...@flightlab.com> wrote:
> tom.rmadilo wrote:
>
>
> Conceptually [*], evaluating anything in Tcl yields a 3-tuple
> (code, value, options), where the return code is a small integer
> (0 = ok = TCL_OK; 1 = error = TCL_ERROR, etc.), the return
> value is a string (what's usually thought of as the "result"),
> and the return options are a dictionary of extra qualifiers
> containing things like -errorcode and -errorinfo (for TCL_ERROR)
> or -returncode and -returnlevel (for TCL_RETURN).
>
> So for instance [string index "abc" 0] returns (ok, "a", {}),
> and [expr {2+2}] returns (ok, "4", {}).
>
> [while] and [foreach] are no different here. They usually
> return (ok, "", {}) but may also return (error, "..message",
> { -errorcode ... -errorinfo ... }) if evaluating the body
> raises an error; or (return, "...", { ... }) if the body
> calls [return]; or something else entirely if the body
> produces a nonstandard return code.
>
> [break] and [continue] are only "special" in that they
> return (break, "", {}) and (continue, "", {}), respectively,
> while most "normal" commands usually return (ok, ..., {})
> or (error, ..., {...}). But that's not really "special"
> or unusual; they're used for nonstandard control flow
> so naturally they return a nonstandard return code.
>
> Also note that [break] and [continue] *do* produce a return value --
> the empty string -- as can be seen with [catch { break } result].
>
> You can produce a nonempty return value with a TCL_BREAK
> return code as well: [return -code break "Ouch! It broke"].
> There's rarely a reason to do so, though, because none of the
> existing control constructs that pay attention to TCL_BREAK
> and TCL_CONTINUE return codes do anything with the return value.
>
> Note that _all_ Tcl operations produce such a 3-tuple:
> evaluating a script, invoking a command, and even variable
> substitutions -- when evaluating [puts "$a$b$c"], the
> "$a" substitution normally returns (ok, "... value of 'a' ...", {}),
> or (error, "can't read "a": no such variable", { ... }).
> And if there's a read trace on "a", it can return almost
> anything.
>
>
> The empty string is a 0-length sequence of characters.
> There is only one such sequence. It is unique. If you
> want to distinguish "real" empty strings from "meaningless"
> empty strings, you're off into the realm of metaphysics;
> have a good time while you're there.
Let's just talk about what it means for a command to 'return'. At the
Tcl script level, a command returns iff evaluation continues at the
point it left off in the current context. [break] and [continue] don't
do this. What they do is to cause other things to happen, maybe an
error is generated, maybe a loop is broken or continued at the next
iteration. [return] is the same. It may set the Tcl result, but it
doesn't 'return', it causes something else to happen. So there are
three types of commands, if you just consider return. Those which
return a meaningful value [regexp], [expr], etc., those which return
meaningless values [foreach], [upvar] maybe others, and those which
don't return [break], [return], etc.
|