Re: Puzzled about scope/existence of globals

[Tomer Altman]

Ah, okay. Now its clearer.

Here's where my confusion lies:

There's no analog of 'clear' that operates on globals. It just clears
local/current scope references to global variables. I expect, when I
do the following:

global x;
x = 5;
clear x;

For x the be completely obliterated. I simply don't see the point
otherwise. I mean, unless you want to write messy code like this in a
function:

function y = foo()

global x;

y = x;

clear x;

x = bar();

y = y + x;

endfunction

This would be considered very bad style in any structured programming
language; using one variable identifyer to represent two different
values of different scope within the same context. But that is the
only thing that I can think of where "clearing a global" makes any
sense.

Would it be possible to have the following?

global x;
x = 5;
clear("x","global");

---

Cheers,

~Tomer


On Nov 22, 2003 at 10:17pm, John W. Eaton wrote:

jwe >Date: Sat, 22 Nov 2003 22:17:14 -0600
jwe >From: John W. Eaton <address@hidden>
jwe >To: address@hidden
jwe >Cc: Glenn Golden <address@hidden>, address@hidden
jwe >Subject: Re: Puzzled about scope/existence of globals
jwe >
jwe >On 22-Nov-2003, Tomer Altman <address@hidden> wrote:
jwe >
jwe >| You know what? I was starting to notice some of the same strangeness,
jwe >| but I became distracted & never fully investigated it. Poking around,
jwe >| I've noticed some oddities:
jwe >
jwe >I think you also said you were working with 2.1.40, which is old, but
jwe >you would only see one difference with 2.1.51 which is that global
jwe >values are always intialized to [] unless you specifically initialize
jwe >them yourself.  This changes the behavior of your second function.
jwe >
jwe >| function scope_fun
jwe >| 
jwe >| if ( ! exist("x","var") )
jwe >|   global x = "foo"
jwe >|   x
jwe >| else
jwe >|   global x = "bar"
jwe >|   x
jwe >| endif
jwe >| 
jwe >| endfunction
jwe >| 
jwe >| octave> scope_fun
jwe >| x = foo
jwe >| octave> x
jwe >| error: `x' undefined near line 5 column 1
jwe >| octave> global x
jwe >| octave> x
jwe >| x = foo
jwe >| octave> x = 5
jwe >| x = 5
jwe >| octave> scope_fun
jwe >| x = 5
jwe >| octave> clear x
jwe >| octave> x
jwe >| error: `x' undefined near line 10 column 1
jwe >| octave> scope_fun
jwe >| x = 5
jwe >| octave> x
jwe >| error: `x' undefined near line 12 column 1
jwe >| octave> 
jwe >| 
jwe >| ---
jwe >| 
jwe >| My off-the-cuff analysis is that there is, in fact, somehow, *TWO*
jwe >| global scope name-spaces: one for the interpreter environment, and one
jwe >| for the "compiled" M-file environment. What I think is happening, is
jwe >| that as soon as one is updated, it will try to "sync" with the other
jwe >| environment. Of one of those global scopes' variables is 'cleared',
jwe >| then the other one persists. Also, it seems that the interpreter
jwe >| environment is "dominant", when they "sync"...
jwe >
jwe >I'm not sure why you are guessing about the behavior.
jwe >
jwe >| Here's the same test, but from the opposite perspective:
jwe >| 
jwe >| ---
jwe >| 
jwe >| function scope_fun2 
jwe >| 
jwe >|   global x;
jwe >| 
jwe >|   x
jwe >| 
jwe >|   clear x;
jwe >| 
jwe >|   x
jwe >| 
jwe >| endfunction
jwe >| 
jwe >| octave> scope_fun2
jwe >| error: `x' undefined near line 5 column 3
jwe >| error: called from `scope_fun2' in file
jwe >| `/home/taltman/taltman-judean/code/octave/M-files/scope_fun2.m'
jwe >
jwe >With 2.1.51, you would see
jwe >
jwe >  ans = [](0x0)
jwe >
jwe >for line 5, then the undefined variable error on line 9 after the
jwe >clear statement.
jwe >
jwe >| octave> global x
jwe >| octave> x = 5
jwe >| x = 5
jwe >| octave> scope_fun2
jwe >| x = 5
jwe >| error: `x' undefined near line 9 column 3
jwe >| error: called from `scope_fun2' in file
jwe >| `/home/taltman/taltman-judean/code/octave/M-files/scope_fun2.m'
jwe >| octave> x
jwe >| x = 5
jwe >| octave> 
jwe >| 
jwe >| ---
jwe >| 
jwe >| So I guess this bizarreness is due to how 'clear' operates, as well.
jwe >
jwe >I don't think it is bizarre, so perhaps you can point out specifically
jwe >where you think it is bizarre, and the behavior you expect, and why.
jwe >
jwe >Think of each global variable behaving as though it exists in its own
jwe >named Fortran COMMON block.  Clearing a global is like deleting that
jwe >COMMON block from the scope in which the clear statement appears.  The
jwe >globals associated with a function are created the first time a global
jwe >statement inside a function is evaluated, but do not disappear when
jwe >the function exits (that way, they are persistent across a function
jwe >call, even if they are only mentioned inside one function).
jwe >
jwe >AFAIK, this is all Matlab-compatible behavior (with the exception of
jwe >allowing initialization in the global statement as an extension -- to
jwe >get that in Matlab, you have to do some extra work).  If you find some
jwe >way that global variables in Octave's do not work the same as they do
jwe >in Matlab, then please describe precisely how Octave's current (i.e.,
jwe >2.1.51 or later) behavior is different.  If you simply don't like the
jwe >way that globals work in Matlab, then I think you should be asking
jwe >questions about that over in comp.soft-sys.matlab.
jwe >
jwe >jwe
jwe >



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------