Why can't or why shouldn't Matlab "re-shadow" functions after eval() is called?

I know eval() is not to be encouraged. Nevertheless, I still wonder why errors like in the code below are still around after so many years and releases. Is it so problematic for Matlab to re-examine the list of variables in the workspace after eval() is issued and properly shadow any functions with name conflicts? I realize this might have to be less efficient than if eval() were absent, but why is it inevitable that an error be generated?

test

Warning: Identifier 'fft' in the evaluated statement does not refer to the external function. In a future release, using an identifier different to how it is used in the file will not be supported.

  Name      Size            Bytes  Class     Attributes

  fft       1x1                 8  double              

Error using fft
Not enough input arguments.

Error in solution>test (line 9)
disp(fft)

function test

    eval('fft=1;');
    
    whos fft
    
    disp(fft)
    
end

Answer 1

[Walter Roberson]

Check the Language and Programming release notes for R2021a, "eval function". The warning is new transitional behaviour, and in some future release, it will be an error.

We are discussing efficiency in a different thread, in which you are suggesting removing some backwards compatible behaviour. This change removes some backwards compatible behaviour to improves efficiency.

[Matt J]

The warning is new transitional behaviour, and in some future release, it will be an error.

The warning may be new, but the error thrown later in the call to disp has always been there, or at least I first tripped over it back in R2010 or so. It's that error which my post refers to when it asks if it could be avoided. Notice that the call to whos() successfully recognizes that fft is a double variable, so it is puzzling that disp cannot.

[Steven Lord]

whos displays the contents of the workspace at runtime. It has to in order to list variables that were (for example) load-ed into the workspace.

The disp command is actually irrelevant here. What matters is that MATLAB has to determine at parse time to what the identifier fft refers. Since there is no indication the parser can see that fft is a variable (no, it can't look at the text that will be evaluated by the eval statement at runtime) and there is a function named fft MATLAB decides that fft refers to that function.

If you wanted MATLAB to reparse your function every time the meaning of an identifier could have changed, it could need to reparse after every single function call and that could have a significant impact on performance. Off the top of my head:

• evalin or assignin executed in the function that was called could have cleared a variable or added one.
• That function could have manipulated the MATLAB path to add, remove, or modify the function that MATLAB associated with an identifier during a previous parsing cycle.
• timer object TimerFcns and graphics object callback functions could potentially manipulate the workspace.
• The user could have added or removed a function from the file system from outside MATLAB between parse cycles. This could include creating a MEX-file or a P-coded file with the same name as an identifier in the workspace to take precedence over the MATLAB script, function, or class file. If a network directory with a slow connection was on the MATLAB path this could be particularly painful.
• There may be something tricky one could do accessing MATLAB as a COM automation server.

The first three MATLAB may be able to detect. The fourth could be tricky and/or quite slow. I'm not quite sure about the fifth.

[Matt J]

@Steven Lord What if we were to suppose that reparsing occur only after calls to the eval/evalin/assignin family. The impact on performance would be minimal, correct? And the impact would only occur if eval were to be used, which would hopefully be rare, right?

[Walter Roberson]

Release notes, R2019b, Functionality being removed or changed

Starting in R2019b, MATLAB changes the rules for name resolution, impacting the precedence order of variables, nested functions, local functions, and external functions. These rules are described in Function Precedence Order. For information about the changes and tips for updating your code, see Update Code for R2019b Changes to Function Precedence Order.

• Identifiers cannot be used for two purposes inside a function.
• Identifiers without explicit declarations might not be treated as variables.
• Variables cannot be implicitly shared between parent and nested functions.
• Change in precedence of compound name resolution.
• Anonymous functions can include resolved and unresolved identifiers.

Regardsless of what happened before R2019b, it is now deliberate behaviour that you cannot use fft as both a function and a variable, and that it is acceptable for MATLAB to not notice that a name has switched to being a variable.

[Matt J]

@Walter Roberson OK, but I think you're making a point that is pertinent to a different thread. The question in this thread is whether MATLAB could detect and avoid the name conflict created by eval if it wanted to.

[Walter Roberson]

Mathworks made it clear with the release notes for R2019b that it does not want to do that. It resolved the situation in favour of making it a warning (now) and an error (soon.)

I do not know if they made the design decision first and tightened up the analysis afterwards to detect it, or if they tightened up the analysis and then realized that they had to make a design decision. I would like to think that it is part of a sustained drive to improve efficiency by closing down any remaining sloppy loopholes and making what remains as efficient as they can get.

[Stephen23]

"Notice that the call to whos() successfully recognizes that fft is a double variable, so it is puzzling that disp cannot."

Your comparison of calling WHOS and some function call (as Steve Lord points out) is comparing apples and oranges. The documentation here

https://www.mathworks.com/help/matlab/matlab_prog/techniques-for-improving-performance.html?searchHighlight=performance&s_tid=srchtitle_performance_3#buwj1nn

specifically advises to "Avoid functions that query the state of MATLAB such as inputname, which, whos, exist(var), and dbstack. Run-time introspection is computationally expensive": so what you ask for would require performing "computationally expensive" introspection (just like WHOS does now) to resolve the function every single time any function is called.

"The question in this thread is whether MATLAB could detect and avoid the name conflict created by eval if it wanted to."

As a design decision it certainly could, as WHOS proves... but it would have a significant time cost, just as WHOS does already. You basically have to throw out the JIT engine.

[Matt J]

so what you ask for would require performing "computationally expensive" introspection (just like WHOS does now) to resolve the function every single time any function is called.

Why "any function"? If it's already possible to confine the repercusions to select function calls like WHOS, then why not for EVAL as well?