Robert SeegerRobert SeegerDon Porter$Revision: 1.6 $Tcl

This TIP proposes adding a new subcommand to the info command to get a list of all the frames on the current stack, rather than the limited list returned by info level.

Currently, there is no way to get a list of all the frames in the current stack managed by Tcl_PushCallFrame() and Tcl_PopCallFrame(). The info level command does not contain frames that are callers of uplevel, reporting only the frames that are accessible via another uplevel command. There are times when the lack of information can have a negative impact on code design. The difference in information can be seen with the following code snippets: JSBwcm9jIGJvYiB7YXJnc30geyA=ICAgIGpvZSB7ZXhwYW5kfSRhcmdzICB9JSBwcm9jIGpvZSB7YXJnc30gew==ICAgIHVwbGV2ZWwgMSBkYXZlIHtleHBhbmR9JGFyZ3M=ICB9JSBwcm9jIGRhdmUge2FyZ3N9IHs=ICAgIHB1dHMgIkxldmVsOiBbaW5mbyBsZXZlbF0iICAgIGZvciB7c2V0IGkgW2luZm8gbGV2ZWxdfSB7ICRpID4gMCB9IHtpbmNyIGkgLTEgfSB7ICAgICAgcHV0cyAiJHtpfTogW2luZm8gbGV2ZWwgJGldIg==ICAgIH0=ICB9JSBib2IgeCB5IHo=TGV2ZWw6IDI=MjogZGF2ZSB4IHkgeg==MTogYm9iIHggeSB6JSBwcm9jIGRhdmUge2FyZ3N9IHs=ICAgIHB1dHMgIkxldmVsOiBbaW5mbyBmcmFtZV0iIA==ICAgIGZvciB7c2V0IGkgW2luZm8gZnJhbWVdfSB7ICRpID4gMCB9IHtpbmNyIGkgLTEgfSB7ICAgICAgcHV0cyAiJHtpfTogW2luZm8gZnJhbWUgJGldIg==ICAgIH0=ICB9JSBib2I=TGV2ZWw6IDM=MzogZGF2ZSB4IHkgeg==Mjogam9lIHggeSB6MTogYm9iIHggeSB6 There are 3 reasons I see for bringing forth this TIP: It's an introspection ability that is currently lacking, with no good reason for that lack.The more information that is available to the programmer, the easier it is to accomplish a goal in a straightforward, easily maintainable way.I have code in which the impact of not having this information available is visible. There are two cases I have run into where the ability to query all frames on the stack would have been particularly useful. TclTestThe first case is with Tcltest, where the complete lack of ability to gain access to that information means it is impossible to gain information about a test without modifying the Tcltest code itself. Being able to find out the name of the current test would be very handy, especially in naming test procs and logging information. Currently, there is no way to find out the name of the currently executing test, due to the fact that the code for the test is upleveled and, hence, not visible via info level.TestStubs PackageThe TestStubs package provides the ability to temporarily redefine commands, in particular for stubbing out or replacing functionality in a test case. There is a command in the package called chain, which is used within the code replacing a command (or part of a command) to call the original definition of the command. For example, one could do:c3R1YnM6OnN0dWIgZW5zZW1ibGUgYXJyYXkgbmFtZXMgew==ICAgIHJldHVybiBbbHNvcnQgW3VwbGV2ZWwgMSBjaGFpbiBuYW1lcyAkYXJnc11dfQ==However, since the chain command is (and should be) limited to only running from within a stub definition, it needs to call info level to find out if its caller is one of the stubbed commands, and what the name of that command is. With info level, it would not have access to the level that is running inside the stubbed procedure. Hence, either it cannot check this constraint, or stubs cannot be allowed to use uplevel when calling it (which means things like the above either cannot work, or need to be rewritten in a considerably less clear manner).

I propose to add a new subcommand to the info command with the following syntax: info frame ?level? The new functionality will provide access to all frames on the stack rather than the current limited subset. The information to do so already exists within the Interp object that all commands are passed, and the code needed to expose it differs in only a few aspects from that of info level. This TIP does not propose to alter uplevel or upvar so that they can see these hidden levels. The current implementation of info level only returns levels up to the top of the stack for the current interpreter. Such an approach puts limitations on what information can be retrieved, but allows for a certain level of "security" when running code in child interps, especially safe interps. Given the security considerations of safe interps, and consistancy with regards to what information is returned across multiple circumstances, the stack trace returned will only return information up to the top level of the current interp, the same limit info level is bound by.

An implementation patch is available on SourceForge [].

This document has been placed in the public domain. Please note that any correspondence to the author concerning this TIP is considered in the public domain unless otherwise specifically requested by the individual(s) authoring said correspondence. This is to allow information about the TIP to be placed in a public forum for discussion.