[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Puzzled about scope/existence of globals
From: |
Tomer Altman |
Subject: |
Re: Puzzled about scope/existence of globals |
Date: |
Sat, 22 Nov 2003 21:50:24 -0800 (PST) |
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
-------------------------------------------------------------
Re: Puzzled about scope/existence of globals, Tomer Altman, 2003/11/22