Internal DynamicModule steals scope of external DynamicModule

Question

I have two dynamic objects, one nested in the other. Both have their own functions defined, as follows. I have simplified them to the point where they don't make much sense, but can still illustrate my problem. When evaluated like this, it works as expected:

ClearAll[inner, outer];
inner[Dynamic[x_, args___]] := DynamicModule[{updateInner},
   updateInner[] := (Print@"inner"; args@1);
   Slider[Dynamic[x, (updateInner[]; x = #) &]]
   ];
outer[Dynamic[x_, args___]] := DynamicModule[{updateOuter},
   updateOuter[] := (Print@"outer"; args@1);
   {inner[Dynamic[x, (updateOuter[]; x = #) &]], Dynamic@x}
   ];

x = 1;
outer[Dynamic@x]

Any movement of the slider produces an "inner" - "outer" pair.

However, when I rename both update functions to the same update, outer will use the inner update instead of its own.

ClearAll[inner, outer];
inner[Dynamic[x_, args___]] := DynamicModule[{update},
   Print@{"inner:", SymbolName@update};
   update[] := (Print@"inner"; args@1);
   Slider[Dynamic[x, (update[]; x = #) &]]
   ];
outer[Dynamic[x_, args___]] := DynamicModule[{update},
   Print@{"outer:", SymbolName@update};
   update[] := (Print@"outer"; args@1);
   {inner[Dynamic[x, (update[]; x = #) &]], Dynamic@x}
   ];

x = 1;
outer[Dynamic@x]

 {outer:, update$337}
 {inner:, update$338}

This issues $RecursionLimit::reclim2: Recursion depth of 1024 exceeded during evaluation of x=1. >> and only "inner" is printed, never "outer". Note, that the two symbol names are (inner and outer update) not identical: update$337 and update$338.

Of course I can always rename one update function to something else, but relying on renaming when seeking robustness is never ok. How to design GUI objects that have update functions and can be safely embedded in outer GUI objects, with function-forwarding using the second argument of Dynamic?

Localizing update functions with a Module is not a good idea as the update function might rely on dynamic variables (on my real case it does).

Answer 1

This answer builds on @AlbertRetey's answer where, in the comments, you wanted some guidance as to how Wolfram creates robust controls.

Think very carefully about the division of labor between the FE and the kernel. You've effectively embedded the entire implementation inside the FE by putting the update functions in DynamicModules. Generally, this is a mistake for anything you wish to be general and nontrivial. It's better to have the implementation be in a single, versioned, interface function which exists in kernel code that can be referenced by the control.

IntervalSlider provides a good example. IntervalSlider typesets into something which is basically a reference to the function NotebookTools`CustomSliderDisplay. This code is still going to generate its own DynamicModule which, in principle, could have the same sort of naming conflicts you're pointing out. But the code has been defined now in a private context, which means all of the DynamicModule variable names are now in their own context, and so it would basically take user maliciousness to cause a problem. And many things may not need to be represented at all in a DynamicModule. Your specific example falls in the latter category.

So, then, your inner definition might look something like this:

ClearAll[inner, outer, update];
Remove[update]
inner[Dynamic[x_, args___]] := 
  Interpretation[
   Dynamic[inner`innerDisplay[1, Dynamic[x, args]], TrackedSymbols :> {}], 
   inner[Dynamic[x, args]]];
Begin["inner`Private`"];
update[args___] := (Print@"inner"; args@1);
inner`innerDisplay[1, Dynamic[x_, args___]] :=      
  Slider[Dynamic[x, (update[args]; x = #) &]];
End[]

Your typeset Dynamic now has exactly one kernel dependency: innerDisplay. As long as you make sure that this is properly loaded, which might involve setting the outermost Dynamic to load a package in its Initialization, then you're in good shape.

The first argument of innerDisplay is a versioning argument. It leaves you flexibility if you want to change things in the future while supporting backward compatibility with notebooks that have older constructs in them.

Answer 2

The cause is the variable name confusion. It is true that each DynamicModule creates different symbol names. However, a new symbol name is generated again in Dynamic. For example, try running this code and slide the slider:

DynamicModule[{x = 0, f}, f[] := Print[SymbolName@f];
 f[]; Slider[Dynamic[x, f[] &]]]

(* f$400707 *)
(* Slider *)
(* f$$3152 *)

f$$3152 is printed when you move the slider.

Using OP's code construction + some modifications:

ClearAll[inner, outer];
inner[Dynamic[x_, args___]] := DynamicModule[{update},
   update[] := (Print@update; Print@args);
   update[];
   Slider[Dynamic[x, update[] &]]];
outer[Dynamic[x_, args___]] := DynamicModule[{update},
   update[] := (Print@update);
   update[];
   {Slider[Dynamic[x, update[] &]],
    inner[Dynamic[x, update[] &]]}];
x = 1;
outer[Dynamic@x]

(* update$405810 *)
(* update$405811 *)
(* update$405810[] & *)
(* 2 Sliders *)
(* FE`update$$3176 *)
(* FE`update$$3177 *)
(* FE`update$$3177[] & *)

The 3176 is printed when you move the first slider (outer). The two 3177s are printed when you move the second slider (inner). The first three lines of output is the expected behavior (args refers to update in outer (405810) not inner (405811)), which is correct, but the last three lines are the actual behavior (args refers to update in inner (3177) not outer (3176)).

This creates name confusion as I stated in the first comment, causing Mathematica to use the definition of update defined by inner for all instances of update.

Answer 3

This is probably not really an answer but definitely too long for a comment.

First thing that seems worth mentioning is that the following part of the documentation for InheritScope can be interpreted as if the behavior you see is an intended feature:

With the setting InheritScope->False, a DynamicModule will continue to inherit variable settings from a parent instance that wraps the DynamicModule instance onscreen.

I have not found and am not aware of a possibility to switch this off (InheritScope just controls such inheritance between DynamicModule instances which are not nested on screen).

Another detail that becomes more clear when slightly adjusting the first example in JHMs answer is why there are two symbols generated per DynamicModule-Variable: one is generated in the kernel and one in the frontend:

DynamicModule[{x = 0, f}, 
   f[] := Print[Context@f -> SymbolName@f];
   f[]; 
   Slider[Dynamic[x, f[] &]]
]

That is of course not much of a surprise. More interesting is that even in the frontend two different symbols for the inner and outer update are generated, so it looks like there is even extra effort involved to achieve the documented behavior.

I see at least two workarounds to overcome that problem:

Use Contexts/Namespaces

The first is to define inner and outer in two different private contexts. That is something that I would recommend to do anyway if you want to achieve maximal independence of your functions. You might also see my question and answer here, where I describe a different potential problem which also can be cured or at least mitigated in most cases with that approach.

Use a kernel symbol and handle lifetime of that yourself

Another approach is to use a temporary unique symbol to define the update function and remove it yourself when not needed anymore, here is an example how that could be achieved:

With[{update = Symbol[StringReplace[CreateUUID["u$"], "-" -> ""]]},
  DynamicModule[{x = 0}, 
    Slider[Dynamic[x, update[] &]],
    Initialization :> (
      update[] := Print[Context@update -> SymbolName@update];
      update[]
    ),
    Deinitialization :> (
      Print["cleanup: ",HoldForm[update]]; Remove[update];
    )
  ]
]

Note that with this approach you are loosing the functionality that DynamicModule variables will automatically be stored in the Notebook when that is saved, so you will need extra care to initialize if you need that to work. For the kind of local function definitions you have in mind that can easily be achieved with the Initialization option as shown above, which by the way at least for me makes the code somewhat clearer by explicitly stating what part of it actually is initialization. This also makes clear that we need to generate a symbolname which will be unique even in a new session, which can either be (statistically) ensured with the use of CreateUUID or maybe also something like: StringJoin["u$", ToString[$SessionID], "$", ToString@$ModuleNumber].

Another detail that even might be an advantage is that there is now no frontend symbol for update generated anymore, which for the intended purpose seems to not be of any relevance and only adds overhead. It is probably interesting to note that due to that fact this approach can also be used to solve the problem that largish data in DynamicModule variables sometimes makes the gui stuff become unresponsive because the largish data is passed from frontend to kernel for every update.

Of course this approach is depending on the deinitialization to work correctly and reliably, otherwise it might become a memory leak...

Answer 4

JHM is right about the reason. John Fultz shows nice versioning and coding style I'm encouraging to use. Yet there is no answer to how to avoid this problem in general and flexible way.

Here is my attempt, I will skip JF enhancement to not complicate things but it can be used with this method too.

The problem is that whatever symbol name we use it may happen that the collision will occur as soon as our name will already be somewhere on $ContexPath (at a time of parsing those two controllers). It would be nice to don't have to come up with unique symbols which are not readable and handy, for every piece of code we write.

The solution is to ensure that the context in which update is parsed will be unique.

We can achieve this sticking to two rules:

• each "modular" gui element should be defined in own "subcontext"

  So e.g. between Begin["`inner`"]/End[]

• DynamicModule variables should be typed with a backtick `update so that we are sure that even when update is somewhere in $ContexPath "our" update will be `inner`update.

Here is a minimal example of such package:

ClearAll["GUI`*"];
BeginPackage["GUI`"];
inner; outer;
  update (it isn't part of the solution, it is here to simulate 

           "update" being on context path)
Begin["Private"];
Begin["inner"];
inner[Dynamic[x_, args___]] := 
    DynamicModule[{update}, Print@{"inner:", SymbolName@update};
      update[] := (Print@"inner"; args@1); Slider[Dynamic[x, (update[]; x = #) &]]];
End[];
Begin["outer"];
outer[Dynamic[x_, args___]] := 
    DynamicModule[{update}, Print@{"outer:", SymbolName@update};
     update[] := (Print@"outer"; args@1); {inner[Dynamic[x, (update[]; x = #) &]], Dynamic@x}];
End[];
End[];
EndPackage[];

Now, since we have GUI`Private`inner`update and GUI`Private`outer`update there is no collision. Which was achieved with minimal effort and works even when GUI`update is on $Path during parsing.

x = 1;
outer[Dynamic@x]

Prints inner/outer