Tcl Source Code

Unless I have missed something in the docs (which is 
entirely possible at this hour), this behaviour is either a 
bug or a documentation oversight.  

Is there some bad interaction here between slave 
interps and [interp alias]?  Perhaps the combination of 
slave interps and namespaces triggers this problem?  

If this is NOT a bug, it is still downright confusing.  
Having [info level] "skip over" a caller in the stack is not 
ideal.

----

namespace eval ::test {
  proc procA { interp } {
    if {$interp} then {
      global i
      interp alias $i ::test::A::procB {} ::test::procB
      interp eval $i [list namespace eval ::test::A procC]
    } else {
      interp alias {} ::test::A::procB {} ::test::procB
      namespace eval ::test::A procC
    }
  }

  proc procB {} {
    set current [lindex [info level [info level]] 0]

    # should print "::test::procB"
    puts stdout "current ([info level]) == $current"

    if {$current == "::test::procB"} then {
      puts stdout "SUCCESS, current proc match."
    } else {
      puts stdout "FAILURE, current proc mismatch."
    }

    set parent [lindex [info level [expr {[info level] - 1}]] 
0]

    # should print "::test::A::procC" or "procC"
    puts stdout "parent ([info level] - 1) == $parent"

    if {[string match "*procC" $parent]} then {
      puts stdout "SUCCESS, parent proc match."
    } else {
      puts stdout "FAILURE, parent proc mismatch."
    }
  }
}


foreach this_interp [list 0 1] {
  puts stdout "Running test with use_new_interp set to 
$this_interp."

  if {$this_interp} then {
    set i [interp create]
    
    interp eval $i {
      namespace eval ::test::A {
        proc procC {} {
          procB
        }    
      }
    }
  } else {
    namespace eval ::test::A {
      proc procC {} {
        procB
      }    
    }
  }
  
  ::test::procA $this_interp
}

Logged In: YES 
user_id=113501


Since this appears to be by design, perhaps we can address
it in the 9.0 timeframe (maybe with an optional arguments
that allow you to "escape" out of the child interp, if the
master allows it):

interp set varName ?value?
info level ?level? ?list_of_interps?

etc

Logged In: YES 
user_id=79902

It's possibly the case that we need [interp set], but it is
usually not to big a problem in practice.

Inter-interp [upvar] is deeply evil.  I don't want to be
that scared.

Logged In: YES 
user_id=113501

Actually, such a feature might be desirable in some 
circumstances (primarily when a safe interp calls a proc in a 
master interp that needs to modify variables in the calling 
child proc via upvar, etc).

Logged In: YES 
user_id=80530


Note that the "level"s reported
on by [info level] are the same
ones which govern [uplevel] and
[upvar].  That might explain
why only the current interp's
CallFrames are tracked.  You would
not want an [uplevel] to cause 
substitution/evaluation in a different
interp.

Logged In: YES 
user_id=80530


It's probably fair to say this
is underdocumented.

[info level] does not trace back
through the caller sequence,
weaving in and out of interps.
Instead, it reports the stack
of CallFrame's for the current
interp only.

This is intentional, though you
may need to consult with the
original [interp] creators to get
a best explanation of the reasons
why.  If Jacob Levy is available,
he might be able to fill in more
details.

File Added - 89728: call-stack.tcl

File Added - 89675: test.tcl