Re: Compatibility considerations of "clear"

[Philipp Kutin]

On Wed, Aug 14, 2013 at 6:24 PM, Ben Abbott <address@hidden> wrote:
> -----------
> If X is global, clear X removes X from the current workspace, but
> leaves it accessible to any functions declaring it global.
> (...)
> -----------

Heh, that sentence is thoroughly confusing. The way I see it and from
experience, MATLAB behaves like this: to have a global, i.e.
process-wide variable, you first "declare" it using "global
<varname>". If it does not exist in the global workspace, it gets
initialized with the empty matrix. From this point on, <varname>
refers to that single instance of the variable *in this function*.

The second, orthogonal, issue is how you access this variable from
other functions (or at the prompt). Simply writing <varname> does
*not* refer to the global, but to a variable of the same name in that
workspace from whose context the reference happens (I'll refer to it
as the "current" workspace from here on). Thus, you must also declare
the global in the other function to access it.

So far, so good. How does "clear" behave? Without any additional
arguments, it clears all names from the current workspace. For
non-global variables, the memory pertaining to each name may also be
freed (more exactly, only if the then-decreased reference count
reaches zero, of course), because there is then no way of accessing it
any more. However, this is not the case with global variables: it it
unknown where they might be accessed from.

So summarizing, for globals:
- "clear <varname>" merely removes the way of accessing the global by
its name (i.e. makes the name refer to a function-local variable again
[*]).
- "clear global <varname>" also frees the memory associated with the
variable of that name.

[*] I don't know the specifics of what happens if a global variable is
declared that shadows an already existing local one, but I guess that
it's what you'd expect.

As example session could look like this (from memory, can't verify right now):
$ global a
$ a
  ans = []
$ a = 5;
$ clear a  % "a" does not refer to the global from here on
$ a
  ??? error: no variable 'a'
$ global a  % let's see it again
$ a
  ans = 5
$ clear global a
$ a  % nope, now it's gone forever
  ??? error: no variable 'a'
$ global a  % initialize it anew
$ a
  ans = []

> Would you file a bug report?

I'll see if I can procude some code if there's general consensus that
this needs fixing. My suggestion is only about changing some already
existing high-level behavior, so I hope I'll manage to see through it.

So, reading the quote from the docs again,
> If X is global, clear X removes X from the current workspace, but
> leaves it accessible to any functions declaring it global.

Here, the five mentions of "X" (the 4th and 5th being "it") refer to
different concepts. De-mystifying,

 "If [the name] X [refers to a variable that] is global, clear [the
string "X" due to command syntax] X removes [the binding of the name]
X [to the global variable named by it] from the current workspace, but
leaves it [the variable data] accessible to any functions declaring it
global."

The last part doesn't make too much sense. We cannot know which
functions are "declaring it global", as they may not have been loaded
yet (or because the global declarations may probably be even from
eval'd code). So the last part should be reading "but leaves the
associated variable in memory" or similar.


On Wed, Aug 14, 2013 at 6:26 PM, Jordi Gutiérrez Hermoso
<address@hidden> wrote:
>> (...) workspace and global variables.
> What's the difference between those two?

By "workspace" I meant the unit of variable scope. Since the MATLAB
language does not have lexically scoped variables, the scope of an
automatic variable is usually a single function. Then there are two
other workspaces: the "interactive" workspace where all your session
vars are stored, and the global workspace, containing all global
variables. That's only describing the conceptual view, not a
particular implementation. As for "persistent", it's more a property
of a variable with function scope than an own scope in its own right
IMO.

> It appears that you have may have neglected reading "help clear"?

Oops, right. Then the only thing I suggest is that globals are not
cleared for the plain "clear" invocation.


--Philipp