Overview
Artifact ID: | 50e6b9e065730ed14fefc844985813aa838386f1 |
---|---|
Ticket: | 8e91ec4866db095f1d90d4e2fd468305a8a80bf8
{TCL LOOKUP VARNAME} vs {TCL READ VARNAME} |
User & Date: | dkf 2015-08-02 16:48:44 |
Changes
- closedate changed to: "2457237.20051545"
- closer changed to: "dkf"
- icomment:
<blockquote><i>That distinction sounds very subtle to me.</i></blockquote> Yes, but that's how it is internally. When you put code into a procedure (well, anything with a Local Variable Table defined) you change how variables are located; simple variable references become a lot more efficient, and the lookup of them no longer fails ever, so no <tt>TCL LOOKUP VARNAME</tt> failure, yet the read might still fail if the variable entry refers to a currently unset variable, hence <tt>TCL VARNAME READ</tt> being the error code. <p> In short, Tcl does not guarantee to give exactly the same reason for failing in all cases where it generates a failure, even if those cases are superficially similar; those cases may be actually looking very different from Tcl's own internal perspective. I don't propose to alter anything, or document that this variation occurs. We might change it all without warning (but probably won't; we're lazy too!)
- login: "dkf"
- mimetype: "text/html"
- resolution changed to: "Rejected"
- status changed to: "Closed"
- subsystem changed to: "07. Variables"
- username: "dkf"