why evalin('caller', 'evalin(''caller'', ''a'')') works in a stack of script. but not a stack of functions?

Suppose three m files of script:

test1.m

a=1;
test2;

test2.m

b=2;
test3;
bb

test3.m

c=3;
evalin('caller', 'evalin(''caller'', ''a'')')
assignin('caller','bb','bbbhahaha');

Then test1 runs OK and shows the value of a;

However, if these scripts are headed with "function *" then error appeared:

Error using evalin Undefined function or variable 'a'.

Error in test3 (line 3) evalin('caller','evalin(''caller'',''a'')');

Error in test2 (line 3) test3;

Error in test1 (line 3) test2;

[dpb]

Per documentation --

Limitation

evalin cannot be used recursively to evaluate an expression. For example, a sequence of the form evalin('caller', 'evalin(''caller'', ''x'')') doesn't work.

[Rik]

Also, why do you want to use evalin in the first place?

[raym]

I just want to get a variable from the upper 2nd stack.

[dpb]

As you've discovered and is documented, "no can do"; at least in any supported manner.

Need to refactor the data structure it seems...

[Stephen23]

Passing variables is efficient. Why not do that?

[raym]

Add variables will change the varargin/out list along the stack layers affected. Sometimes it is not convenient to change the interface of certain functions.

[dpb]

About only supported alternative I see is (ugh!) GLOBAL or perhaps you could recast to incorporate the lower level as nested function inside the higher -- then you have access to all variable at the higher scope outside the argument list but still have local scope within each function.

[Rik]

You can get around global with things like getpref, but I suspect the performance of that is not too great if you use it often. In a GUI of course you would just use guidata, but unfortunately that's not an option here. getappdata with the groot as object might work as well.

[raym]

@ dpd: So do you mean that in a stack contaning a nest function AAA, no matter how many AAAs are nested here this stack,a call of evalin('caller'...) will jump out the nested AAAs,deem the function that calles the most upper AAA as caller, but not the AAA that was just one level upper? That's really interesting.

[Rik]

That might be true (I haven't tested it), but the point is that nested functions can share variables with the outer function.

[dpb]

No, that's nothing at all like what I mean... :)

Nested functions operate in the scoping unit in which they're nested; you should be able to avoid evalin would be the objective.

[raym]

I tested it and found that it is not true:

function NestFun
a = dbstack;
disp(['...I am in the nested level ',num2str(length(a))])
if length(a) > 9
    return
else
    aDouble = evalin('caller','aDouble');
    disp(['...the aDouble in caller is [',num2str(aDouble),']']);
    aDouble = aDouble + 1; 
    NestFun;
end
end

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

    function testNestFun
    aDouble = 0;
    NestFun;
    end

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

>> testNestFun
...I am in the nested level 2
...the aDouble in caller is [0]
...I am in the nested level 3
...the aDouble in caller is [1]
...I am in the nested level 4
...the aDouble in caller is [2]
...I am in the nested level 5
...the aDouble in caller is [3]
...I am in the nested level 6
...the aDouble in caller is [4]
...I am in the nested level 7
...the aDouble in caller is [5]
...I am in the nested level 8
...the aDouble in caller is [6]
...I am in the nested level 9
...the aDouble in caller is [7]
...I am in the nested level 10
>>

[dpb]

Those are not nested functions; that is a function called recursively.

As noted initially, this would require some refactoring of the organization; there is no documented/supported way to extend the reach as you're trying to do.

[Stephen23]

@raym: you might like to read this:

https://www.mathworks.com/help/matlab/function-basics.html

It explains what anonymous, local, and nested functions are, with links for more details. Reading the documentation is a good way to learn how MATLAB works, and what terms mean.

"I tested it and found that it is not true:"

Actually nested functions certainly can access their "parent" function's workspace, just as dpb stated: I use them all the time for this very convenient feature. Your example code does not use any nested function. Note also that any type of function call itself recursively (like in your example code).

Answer 1

[Jan]

While using functions is surely the best answer, the actual question concerned scripts. Then you do not have to call evalin at all but you can access the variables directly. This is the only benefit of scripts:

% file: test1.m
a=1;
test2;

% file: test2.m
b=2;
test3;
disp(bb)

% file: test3.m
c=3;
bb = 'bbbhahaha';
disp(a)

Works. So simply omit the evalin call. Or restructure the code to use functions and inputs/outputs to get a clean and efficient code.

[dpb]

Yeah, if he's always working at the level of the script but my reading is that he's calling existing functions starting from the script in logic-dependent ways such that the variable to which wants access is not always at the same location in the call stack of the caller but in this case specifically a level higher. To get to that variable that is local inside that function isn't doable by scripting alone, either, without turning those functions into scripts as well and that undoubtedly will lead to scoping issues.

I see no way without refactoring at least some...

[Stephen23]

"Or restructure the code to use functions and inputs/outputs to get a clean and efficient code."

Agreed. I still don't see why basic input/output arguments can't be used. I use them all the time for parsing trees using recursive functions in order to extract particular data at particular levels of the tree, and I don't see why a few function calls passing data as inputs/outputs would not be possible here. Playing with the stack is hack code that won't be neat or efficient...