Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Thread Subject:
eval does not shadow variable?

Subject: eval does not shadow variable?

From: Karl

Date: 18 Oct, 2008 01:11:02

Message: 1 of 12

'eval' supposedly "causes Matlab to execute the string as an expression", but in the following example, it does not. Why is this, and how can 'eval' be made to work as expected?

function test

eval('input = 4;') % Does NOT shadow 'input' function with variable

% input = 4; % DOES shadow 'input' function

disp(num2str(input)) % Gives error

Subject: eval does not shadow variable?

From: Srikanth

Date: 18 Oct, 2008 03:13:59

Message: 2 of 12

Seems to work in 2008a
What is the error message you get?

On Oct 17, 6:11=A0pm, "Karl " <kNsOtSaPh...@stanford.edu> wrote:
> 'eval' supposedly "causes Matlab to execute the string as an expression",=
 but in the following example, it does not. =A0Why is this, and how can 'ev=
al' be made to work as expected?
>
> function test
>
> eval('input =3D 4;') % Does NOT shadow 'input' function with variable
>
> % input =3D 4; =A0% DOES shadow 'input' function
>
> disp(num2str(input)) % Gives error

Subject: eval does not shadow variable?

From: Matt Fig

Date: 18 Oct, 2008 04:17:02

Message: 3 of 12

What do you mean by: 'shadow 'input' function'

What error message do you see?


 

Subject: eval does not shadow variable?

From: Loren Shure

Date: 18 Oct, 2008 13:12:53

Message: 4 of 12

In article <gdbd36$ip4$1@fred.mathworks.com>, kNsOtSaPhAlM@stanford.edu
says...
> 'eval' supposedly "causes Matlab to execute the string as an expression", but in the following example, it does not. Why is this, and how can 'eval' be made to work as expected?
>
> function test
>
> eval('input = 4;') % Does NOT shadow 'input' function with variable
>
> % input = 4; % DOES shadow 'input' function
>
> disp(num2str(input)) % Gives error
>
>

This is happening because input is a function on the matlabpath. And,
since you are running this from a function, when that function runs, it
only knows about about the function input, not your variable. If you
choose to not change the name of your variable, here are two choices to
set its value.

Option 1:

input = [];
eval('input = 4;')
...

Option 2:
input = eval('4;')
...



--
Loren
http://blogs.mathworks.com/loren

Subject: eval does not shadow variable?

From: Jan Simon

Date: 18 Oct, 2008 14:18:01

Message: 5 of 12

Dear Karl!

> function test
> eval('input = 4;') % Does NOT shadow 'input' function with variable
> disp(num2str(input)) % Gives error

I do not think the EVAL is a good solution ever. But if you really like it, try:

  function test
  eval('input = 4;');
  disp(num2str(eval('input')));

Dear community: Sorry for this piece of obfuscation.

Good luck, Jan

Subject: eval does not shadow variable?

From: Walter Roberson

Date: 19 Oct, 2008 03:16:59

Message: 6 of 12

Loren Shure wrote:
> In article <gdbd36$ip4$1@fred.mathworks.com>, kNsOtSaPhAlM@stanford.edu
> says...
>> 'eval' supposedly "causes Matlab to execute the string as an expression", but in the
>> following example, it does not. Why is this, and how can 'eval' be made to work as expected?

>> function test
>> eval('input = 4;') % Does NOT shadow 'input' function with variable
>> % input = 4; % DOES shadow 'input' function
>> disp(num2str(input)) % Gives error

> This is happening because input is a function on the matlabpath. And,
> since you are running this from a function, when that function runs, it
> only knows about about the function input, not your variable.

No, that isn't the explanation, or at least it misses the
most important context for why it is relevant.


The explanation has to be something closer to this:

  When matlab reads in the function in the .m file, it parses it
-before- executing it. That parsing includes matching names against
known functions; if there is a name which is a function name, then
if there isn't a -visible- use of the name as a variable name, the
parser will interpret the use of the name as the function, putting
a call into the data structures that represent the .m file contents.
If, at execution time, the name somehow becomes associated with a
variable through a "back door" such as "eval" or "assignin", then it
is too late: Matlab has already decided that it is a function.

  This behaviour is at odds with typical user -expectation- that
each statement is executed sequentially. The behaviour is not the
same as the "Just In Time" (JIT) accelerator, which is a
multi-statement optimizer that applies over the already-parsed code.

Subject: eval does not shadow variable?

From: Loren Shure

Date: 19 Oct, 2008 19:40:20

Message: 7 of 12

In article <DExKk.3640$Zc.298@newsfe09.iad>, roberson@hushmail.com
says...
> Loren Shure wrote:
> > In article <gdbd36$ip4$1@fred.mathworks.com>, kNsOtSaPhAlM@stanford.edu
> > says...
> >> 'eval' supposedly "causes Matlab to execute the string as an expression", but in the
> >> following example, it does not. Why is this, and how can 'eval' be made to work as expected?
>
> >> function test
> >> eval('input = 4;') % Does NOT shadow 'input' function with variable
> >> % input = 4; % DOES shadow 'input' function
> >> disp(num2str(input)) % Gives error
>
> > This is happening because input is a function on the matlabpath. And,
> > since you are running this from a function, when that function runs, it
> > only knows about about the function input, not your variable.
>
> No, that isn't the explanation, or at least it misses the
> most important context for why it is relevant.
>
>
> The explanation has to be something closer to this:
>
> When matlab reads in the function in the .m file, it parses it
> -before- executing it. That parsing includes matching names against
> known functions; if there is a name which is a function name, then
> if there isn't a -visible- use of the name as a variable name, the
> parser will interpret the use of the name as the function, putting
> a call into the data structures that represent the .m file contents.
> If, at execution time, the name somehow becomes associated with a
> variable through a "back door" such as "eval" or "assignin", then it
> is too late: Matlab has already decided that it is a function.
>
> This behaviour is at odds with typical user -expectation- that
> each statement is executed sequentially. The behaviour is not the
> same as the "Just In Time" (JIT) accelerator, which is a
> multi-statement optimizer that applies over the already-parsed code.
>

Perhaps I didn't state my explanation well, but it was intended to be
the same as yours. eval, assignin, load can obscure the introduction of
a variable during MATLAB's parsing of the code.

--
Loren
http://blogs.mathworks.com/loren

Subject: eval does not shadow variable?

From: Steven Lord

Date: 20 Oct, 2008 04:42:47

Message: 8 of 12


"Walter Roberson" <roberson@hushmail.com> wrote in message
news:DExKk.3640$Zc.298@newsfe09.iad...
> Loren Shure wrote:
>> In article <gdbd36$ip4$1@fred.mathworks.com>, kNsOtSaPhAlM@stanford.edu
>> says...
>>> 'eval' supposedly "causes Matlab to execute the string as an
>>> expression", but in the
>>> following example, it does not. Why is this, and how can 'eval' be
>>> made to work as expected?
>
>>> function test
>>> eval('input = 4;') % Does NOT shadow 'input' function with variable
>>> % input = 4; % DOES shadow 'input' function
>>> disp(num2str(input)) % Gives error
>
>> This is happening because input is a function on the matlabpath. And,
>> since you are running this from a function, when that function runs, it
>> only knows about about the function input, not your variable.
>
> No, that isn't the explanation, or at least it misses the
> most important context for why it is relevant.
>
>
> The explanation has to be something closer to this:
>
> When matlab reads in the function in the .m file, it parses it
> -before- executing it. That parsing includes matching names against
> known functions; if there is a name which is a function name, then
> if there isn't a -visible- use of the name as a variable name, the
> parser will interpret the use of the name as the function, putting
> a call into the data structures that represent the .m file contents.
> If, at execution time, the name somehow becomes associated with a
> variable through a "back door" such as "eval" or "assignin", then it
> is too late: Matlab has already decided that it is a function.
>
  This behaviour is at odds with typical user -expectation- that
> each statement is executed sequentially. The behaviour is not the
> same as the "Just In Time" (JIT) accelerator, which is a
> multi-statement optimizer that applies over the already-parsed code.

That's correct, but another wrinkle that may confuse users is that if you
use EVAL in a _script_ file (not a _function_) then the script is
essentially executed one line at a time. It's not parsed ahead of time.
Thus if the OP's example was a script file instead of a function file, then
by the time the code tried to use input as a variable, it would be a
variable.

The moral of the story? DON'T USE EVAL unless you have tried every other
reasonable alternative. In the OP's case, there is a reasonable alternative
that doesn't use EVAL; directly use the line "input = 4;" or use a different
variable name.

--
Steve Lord
slord@mathworks.com

Subject: eval does not shadow variable?

From: Peter Boettcher

Date: 20 Oct, 2008 14:02:57

Message: 9 of 12

"Karl " <kNsOtSaPhAlM@stanford.edu> writes:

> 'eval' supposedly "causes Matlab to execute the string as an
> expression", but in the following example, it does not. Why is this,
> and how can 'eval' be made to work as expected?
>
> function test
>
> eval('input = 4;') % Does NOT shadow 'input' function with variable
>
> % input = 4; % DOES shadow 'input' function
>
> disp(num2str(input)) % Gives error



If you want to keep doing this, the problem is that the just-in-time
compiler can't tell that "input" will ever be a variable, so it compiles
the code to call input as a function. You can help the JIT by
initializing input as a variable somewhere before the eval.

Why would you want to purposely shadow a function, and do so through
Explain the context for this solution, and we can probably provide an
alternative to eval.

-Peter

Subject: eval does not shadow variable?

From: Matt

Date: 20 Oct, 2008 15:25:03

Message: 10 of 12


> Why would you want to purposely shadow a function, and do so through
> Explain the context for this solution, and we can probably provide an
> alternative to eval.

I don't know about the OP's aims, but I ran into this same issue with assignin() when trying to design the function unpackstruct.m below. What I wanted is a way of taking a structure S, and turning all its fields into individual workspace variables (with the variable names the same as the field names of S) with a single command.

The reason I wanted this is so that if I have a structure with many many fields, I sometimes find it cumbersome to access them through the structure all the time. With unpackstruct, I achieve syntax simplicity and cleaner looking code. I see how this might be regarded as laziness, but there you go...

In any case, you can see that unpackstruct() is smart enough to issue a warning if it tries to create a variable that conflicts with a function, but I still find it a disappointing, even if understandable, limitation.


############################################
function unpackstruct(S)
%Takes the fields of the structure S and makes them individual variables
%in the current workspace.
%
%Usage: unpackstruct(S)
%
% !!!!!!!!WARNING!!!!!!!
%
% unpackstruct() will not gracefully create variables when the variable
% name is already in use as a function visible to MATLAB. The "whos"
% command will recognize it as a variable name, but it will still execute
% within the workspace as the pre-existing function.
%
% This has to do with limitations of the assignin() function, which
% unpackstruct() calls. To optimize speed, assignin() does not cross-check
% dynamically created variables with the list of available functions.


flds=(fieldnames(S(:)'));

for fld=flds

 fld=fld{:};

 %%%Necessary to deal with a MATLAB limitation
 s=evalin('caller',['which( ''' fld ''' )']);
 if ~(isempty(s) || strcmp(s,'variable'))
    
   
     str=['Variable name ''' fld];
     str=[str, ''' corresponds to a function and, due to a MATLAB glitch, may not be recognized as a variable'];
     warning(str)
     
 end
 
 
 assignin('caller',fld,getfield(S,fld));

end

Subject: eval does not shadow variable?

From: Walter Roberson

Date: 20 Oct, 2008 17:17:37

Message: 11 of 12

Matt wrote:
 
> %%%Necessary to deal with a MATLAB limitation
> s=evalin('caller',['which( ''' fld ''' )']);
> if ~(isempty(s) || strcmp(s,'variable'))

Instead of using evalin and which, you could probe more directly with

exist(fld, 'builtin') || exist([fld '.m'], 'file') || ...
  exist([fld '.p'], 'file')]

Though this does ignore .MDL files, MEX files, and loaded java classes,
and so might not be sufficient for your purposes. mdl and mex are
obvious extensions based upon file names; the java extension
is exist(fld, 'class')

Subject: eval does not shadow variable?

From: Matt

Date: 20 Oct, 2008 17:56:02

Message: 12 of 12


> If, at execution time, the name somehow becomes associated with a
> variable through a "back door" such as "eval" or "assignin", then it
> is too late: Matlab has already decided that it is a function.

Oddly enough, this doesn't seem to always be true. For example, the following simple function seems to suggest that a "back door" variable will continue to be recognized as a variable long as one continues to access it through eval()

#####################
function shadowtest


 eval('input=4;')

 eval('z=input+4')%This produces output z=8

####################


If it were really "too late" to recognize 'input' as a variable instead of a function, I would expect an error in the second eval()...

Tags for this Thread

No tags are associated with this thread.

What are tags?

A tag is like a keyword or category label associated with each thread. Tags make it easier for you to find threads of interest.

Anyone can tag a thread. Tags are public and visible to everyone.

Contact us