Scilab Bag Of Tricks - Claymore

7.
->a
a =
3.
Obviously, a is unchanged by the calls to baz. What happens is the following:
Chapter 2. Pitfalls
1. A local variable named a is created, and the contents of a from the enclosing scope is copied
into it. Within baz the local a is changed.
2. When the thread of control leaves baz the previous value of a is restored.
In other words: A local variable cannot influence a variable of the same name in any enclosing
scope. The only ways to “export” a – possibly modified – value is either via the list of return values,
which is the preferred way, or with a global variable.
As strange as this may sound to programmers accustomed to languages that require an explicit
declaration of all variables, this is a necessary feature in Scilab as variables are created when they are
first written to (e.g. as in Perl and Python). If a local variable in a function would change a global
variable or local variable of the same name in another function, adding a new function to an existing
system or library became a major maintenance headache.
2.5.2. Global Variables
The global attribute of a variable var is often misunderstood. It does not place var in an all
encompassing name space so that it could be accessed from everywhere without further ado. Instead,
global places the variable var in a separate name space; separate from the interpreter’s name
space, and separate from all local functions’ name spaces. — And this is only the first half of the
story.
->v = -1
v =
- 1.
->global(’v’)
->who(’global’)
ans =
v
->clear v
->who(’global’)
ans =
v
->deff(’y = useglobal()’, ’y = v’)
26