Tcl Source Code

The idiom [uplevel 1 [info level 0]] fails to call the
currently executing proc in some corner cases [Bug
1590483]. Note that this can be fixed by letteing
[interp alias] use fully qualified names.

Should TIP 283 pass, the idiom breakage will be more
widespread: it will not work at all for procs
implementing ensemble subcommands, except in the rarest
of occasions: the ensemble command is called from
within the ensemble's namespace, or from a namespace
that has the ensemble's in its resolution path (and is
not shadowed).

The attached patch provides a new [info call]
subcommand that functions like [info level]. The
difference between the two is that, when a command is
rewritten prior to invocation (by an alias or
ensemble), [info level n] returns the fully rewritten
command (as invoked in the core), whereas [info call n]
returns the original command as present in the source,
after substitutions but before rewrites (as called by
the user).

This is useful for two reasons:
  - to provide a way to call the currently executing
proc again, using [uplevel 1 [info call 0]]
  - to provide a way for procs to produce meaningful
error reports that refer to what the user wrote

Logged In: YES 
user_id=148712

Doh - the available C api is private (fields in ekeko), so
the issue of a C api to use the rewrite engine is there.

Logged In: YES 
user_id=79902

The problem is that some procedure authors (e.g. the author
of clock.tcl) insist on trying to do all that themselves.
Alas, we need a way to accommodate them (and to bear in mind
that they're working against their best interests).

Logged In: YES 
user_id=148712

This does not really need a C api in order for all commands
to produce error messages that refer to the actual input:
Tcl_WrongNumArgs is an example of how to do that, using
ensemble's rewrite and not [info call] directly.

Logged In: YES 
user_id=79902

One adjustment is that I'd like to make [info level $n]
return the fully qualified version of the first command
word, but arrange so that the determining of the first word
only happens when [info level $n] is called, and not
(necessarily) during the call. This postpones computing the
FQN of the command until the instant it is actually needed.

I'm not 100% sure this is a good idea in the presence of
renamed and deleted commands though. :-\

File Added - 201456: call.patch