[Tcl-bugs] [ tcl-Feature Requests-1590790 ] new [info call] command

[SourceForge.net <no...@so...>]

Feature Requests item #1590790, was opened at 2006-11-05 12:32
Message generated for change (Comment added) made by dkf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=360894&aid=1590790&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 17. Commands I-L
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: miguel sofer (msofer)
Assigned to: Donal K. Fellows (dkf)
Summary: new [info call] command

Initial Comment:
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



----------------------------------------------------------------------

>Comment By: Donal K. Fellows (dkf)
Date: 2006-11-05 20:38

Message:
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. :-\

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=360894&aid=1590790&group_id=10894