Version 3 of Introspection shortcomings

This page is about the cases where Tcl's powerful introspection facilities come up short — where there's simply no way to get at a particular piece of information (at least not fram the script level). Hopefully, by collecting them here we may inspire improvements in the language that can provide us with the missing power!

Of course, things might get entered on this page by mistake; maybe there was a way to find the wanted piece of information, it just wasn't what the poster expected? Well, all the better, since it meant Tcl was better! Don't delete the item, but move it down the page to a section of "introspection successes".

Also, there are some things that are unavailable by design (e.g. the type of internal representation in a Tcl_Obj). These also deserve a separate section, since they are not really shortcomings as such.

Introspection shortcomings

vwaited variables

There doesn't seem to be any way of finding out which variables are currently being vwaited upon.

Introspection on aliases

interp always refers to aliases by the name they were created under, so since aliases can be renamed, there's ultimately no way of knowing what an alias command maps to, even if it goes from {} to {}! Consider:

% interp alias {} a {} puts a
a
% interp alias {} b {} puts b
b
% a
a
% b
b
% rename a c
% interp aliases {}
a b
% rename b a
% rename c b
% b
a
% a
b
% interp alias {} a
puts a
% interp alias {} b
puts b

See also: http://sourceforge.net/tracker/index.php?func=detail&aid=707104&group_id=10894&atid=110894

Introspection successes

chan mode

is about extending chan command to query whether a channel is readable and/or writable. Unfortunately it is not part of the Tcl core, but see the referenced pages yourself. (MAKR 2008-07-03)

Lars H: True, but what makes this an introspection success is that the core already provides a way of finding this out:

  catch {read $ch 0}

returns 0 if the channel was readable and 1 otherwise, not changing $ch in either case. Similarly

  catch {puts -nonewline $ch ""}

returns 0 if the channel was writable and 1 otherwise, not changing $ch in either case. Or is there a situation (something with stacked channels, perhaps?) where these actually have a side-effect?