Re: Slave interpreters, aliases, and upvar

Hello,

I understand what Will wants, I understand Richards and Neils
explainations, but ... I don't understand, why this is planned to be
this way.

If I import a namespace command into another namespace, than this
imported namespace command will be executed inside his original
namespace:

% namespace eval ::foo {
variable foo "this is namespace foo";

proc foo {} {
variable foo;

puts "info level 0 .................= '[info level 0]'";
puts "foo ..........................= '$foo'";
puts "namespace current ............= '[namespace
current]'";
puts "info level -1 ................= '[info level -1]'";
puts "uplevel 1 {namespace current} = '[uplevel 1 [list
namespace current]]'";
}

namespace export -clear foo;
}
% namespace eval ::faa {
variable foo "this is namespace faa";

proc faa {} {
foo;
}

namespace import -force ::foo::*;
}
% ::faa::faa;
info level 0 .................= 'foo'
foo ..........................= 'this is namespace foo'
namespace current ............= '::foo'
info level -1 ................= '::faa::faa'
uplevel 1 {namespace current} = '::faa'

In my opinion, the behaviour Will wants/needs would be comparable.

What're the reasons for this design decision?

Best regards,

Martin Lemburg
UGS - Transforming the Process of Innovation

On Apr 12, 10:03 pm, "w...@xxxxxxxxxxxxxx" <will.duque...@xxxxxxxxx>
wrote:
On Apr 12, 8:13 am, Neil Madden <n...@xxxxxxxxxxxxx> wrote:



I think Will wants a different result -- the variable is in the slave
too. It seems that when the master alias is invoked none of the
callframes from the slave are visible (to upvar, uplevel, or info
level). I don't immediately see the reason why a master cannot see the
stack-frames of the slave that invoked it (these aren't safe interpreters).

To solve Will's immediate problem, I'd guess that you could pass the
interpreter handle as part of the alias and read the variables directly:

proc get {interp varName} {
return [$interp eval [list set $varName]]
}
set interp [interp create]
$interp alias get get $interp
$interp eval {
set a 7
get a
}

Happily, this even works inside procs:

$interp eval {
proc foo {} { set b 9; get b }
foo
}

-- Neil

Neil's exactly right, that's what I'm after. And the answer is,
you can't alias a normal proc that uses upvar or uplevel into
a slave interpreter, and expect it to work across the interpreter
boundary the way it works within a single interpreter. You can
write a command that has the same effect, but it has to be
specially written.

I was hoping there was some magic incantation I hadn't run across.
Oh, well.

Thanks, both.

-- Will


.

Relevant Pages

  • Re: macros
    ... (:method ((foo foo) ... (baz baz)) ... I don't see any namespace related anything in that. ... manually managed dispatch tables and plenty of other migraine-inducers ...
    (comp.lang.lisp)
  • Re: pre-PEP: Suite-Based Keywords - syntax proposal
    ... > def foo(): ... suite supplies a transient namespace where foo happens to ... Bengt Richter ...
    (comp.lang.python)
  • Re: Namespace ensembles and interp hide/expose/invokehidden
    ... monolithic commands in the root namespace. ... Even with namespace ensembles, hide/invokehidden is not broken, as long as ... interp eval foo set a b ... then it seems to me that any gains from having this extra command would ...
    (comp.lang.tcl)
  • Re: Class problem
    ... The Assembly Class (part of the System.Reflection namespace) is not ... and the 'URI' is a class definition. ... >>I added that code to the testing classes of foo and foo1. ... >> an example use the Object Browser to goto system.System and you will see ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Followup question on defining methods dynamically
    ... I'm doing something that's not at all object-oriented, and simply want to ensure that a bunch of methods don't leak out into the global namespace. ... The eval would define a 'foo' object in Test, so there would exist a function Test.foo. ... The include statement in Run would cause all names in Test to be imported into Run, resulting in a 'foo' entry in the Run hashmap; ... Finally, code run within a module always has access to the module's namespace for variable lookup, so the call on 'foo' within Run would find 'Run.foo' and execute it. ...
    (comp.lang.ruby)