Scope of variables
mss
I read:
http://www.gnu.org/manual/gawk/gawk.html#Definition-Syntax
'During execution of the function body, the arguments and local variable
values hide, or shadow, any variables of the same names used in the rest
of the program.
The shadowed variables are not accessible in the function definition,
because there is no way to name them while their names have been taken
away for the local variables. All other variables used in the awk program
can be referenced or set normally in the function's body.'
Am I correct in assuming that a variable named 'var' in the main body of
an awk script, and another variable named again 'var' in a user written
function, would not clobber one another?
Also, I'm guessing that this does not apply to predefined (g)awk variables
such as FS, $0, etc...
--
later on,
Mike
Janis Papanagnou
> In section '8.2.1 Function Definition Syntax' of the GNU gawk manual,
> I read:
>
> http://www.gnu.org/manual/gawk/gawk.html#Definition-Syntax
>
> 'During execution of the function body, the arguments and local variable
> values hide, or shadow, any variables of the same names used in the rest
> of the program.
>
> The shadowed variables are not accessible in the function definition,
> because there is no way to name them while their names have been taken
> away for the local variables. All other variables used in the awk program
> can be referenced or set normally in the function's body.'
>
> Am I correct in assuming that a variable named 'var' in the main body of
> an awk script, and another variable named again 'var' in a user written
> function, would not clobber one another?
No. That's only true if that variable is listed as a pseudo formal argument
in the function definition.
{ baz = 42 ; bar = 99 ; foo(5,7) }
function foo (par1, par2, local1, local2, bar)
{
baz = 0 # accesses and resets the global variable
bar = 1 # local to function defined, global variable hidden
}
Janis
pk
> In section '8.2.1 Function Definition Syntax' of the GNU gawk manual,
> I read:
>
> http://www.gnu.org/manual/gawk/gawk.html#Definition-Syntax
>
> 'During execution of the function body, the arguments and local variable
> values hide, or shadow, any variables of the same names used in the rest
> of the program.
>
> The shadowed variables are not accessible in the function definition,
> because there is no way to name them while their names have been taken
> away for the local variables. All other variables used in the awk program
> can be referenced or set normally in the function's body.'
>
> Am I correct in assuming that a variable named 'var' in the main body of
> an awk script, and another variable named again 'var' in a user written
> function, would not clobber one another?
Correct. It's also easy to demontrate:
awk '
function foo(abc, var){
var=99
print "in the function: abc is " abc " and var is " var
}
BEGIN{
var=33
print "before function call, var is " var
foo(12)
print "after function call, var is " var
}'
before function call, var is 33
in the function: abc is 12 and var is 99
after function call, var is 33
However, the same is NOT true for arrays, as is probably explained somewhere
near the paragraph you quoted.
> Also, I'm guessing that this does not apply to predefined (g)awk variables
> such as FS, $0, etc...
There should be another paragraph where that is explicitly addressed. Of
course, $0, $1, etc. are always the same so changing them in a function is
visible outside. Special variables like FS etc. cannot even appear in a
function's argument list IIRC, so they are necessarily global.
Hermann Peifer
There has been a gawk bug fix earlier this year related to reserved variable names as function arguments:
From the gawk ChangeLog:
> Fri May 15 14:10:44 2009 Arnold D. Robbins <arn...@skeeve.com>
> Function arguments cannot be reserved variable names, per POSIX.
You will end up with a fatal error when using FS as function argument
> awk: fatal: function `test': can't use special variable `FS' as a function parameter
Hermann
Kenny McCormack
Janis Papanagnou <janis_pa...@hotmail.com> wrote:
...
>No. That's only true if that variable is listed as a pseudo formal argument
>in the function definition.
>
>{ baz = 42 ; bar = 99 ; foo(5,7) }
>
>function foo (par1, par2, local1, local2, bar)
>{
> baz = 0 # accesses and resets the global variable
> bar = 1 # local to function defined, global variable hidden
>}
Interestingly enough, when I first read your (Janis's) post, I assumed
that you had misread the OP's intent - and thus, I was about to fire off
a typical Usenet flame-response. But, on reflection, I think you are
right (!!! - imagine that, in the context of a Usenet posting...), in
that the intent was to ask whether variables used in an AWK function are
"automatically" localized, as they are in some languages (e.g., TCL).
And the answer to that is, as you note, "no". Unless they are
"protected" by being listed in the parameter list (using the usual
convention for indicating that they aren't "real" parameters), they are
global. That is the way AWK is. Personal note: I think AWK got this
right. Languages (such as TCL, where it is hard, and WinBatch, where it
is [in certain circumstances] impossible) that make it difficult to
access global variables annoy me.
Brian Donnell
wrote:
> In article <hchafr$9o...@svr7.m-online.net>,
Hi, all--
Have you noticed the function addup() on p. 87 of _The Awk Programming
Language_? Takes no arguments; accesses two global variables; keeps
two running totals for successive calls, which it does not return, but
which are visible to END; reinitializes variables in the body. All in
a half-dozen lines.
Best regards, Brian Donnell
mss
Some very subtle distinctions I'll study further.
Slowly, I'm learning awk, such a great language.
--
later on,
Mike
Janis Papanagnou
> Earnest thanks for the insight everyone.
>
> Some very subtle distinctions I'll study further.
> Slowly, I'm learning awk, such a great language.
>
That may sound subtle but it's really easy in case you just want to apply it.
If you want local variables - but *not* local arrays! - in functions, just
declare the variables in the function signature (function "header line").
Per convention, the local variables are separated visibly by a couple blanks.
A function definition:
function myfunction (param, local)
{
print param # the value passed to the function
print local # a locally scoped variable declared in the formal
# parameter list (hides global variables with the
# same name)
print global # a global variable
}
The respective function call:
myfunction(some_value)
Janis
mss
> Per convention, the local variables are separated visibly by a couple blanks.
>
> A function definition:
>
> function myfunction (param, local)
> {
> print param # the value passed to the function
> print local # a locally scoped variable declared in the formal
> # parameter list (hides global variables with the
> # same name)
> print global # a global variable
> }
This really is a good example Janis, reads with much clarity.
Will be placing this little pup in my notes.
--
later on,
Mike
Kenny McCormack
Hermann Peifer <pei...@gmx.eu> wrote:
...
>There has been a gawk bug fix earlier this year related to reserved
>variable names as function arguments:
>
>From the gawk ChangeLog:
>
>> Fri May 15 14:10:44 2009 Arnold D. Robbins <arn...@skeeve.com>
>> Function arguments cannot be reserved variable names, per POSIX.
>
>You will end up with a fatal error when using FS as function argument
>
>> awk: fatal: function `test': can't use special variable `FS' as a
>function parameter
See my other post (response to Ed) as to why I think this was the wrong fix.
Loki Harfagr
Though, it seems that was more like 'the right fix to a wrong problem'
but don't take it bad, that's just a note from one who already saw
several languages disappear in endless wars for the right end of
an egg while the new league pseudo language was burying them.
As you and Ed. put, the problem of living in pure POSIX *should not*
be lived as a /problem/ but as a standard basis for a solid state
program possibility, while when in permissive env. you may use the
bells and extended tools that your favorite brand of dev. lang. allows.
And, yes, it is fine to give suggestions to the language maintainers,
as it is fine that they'd classify some priorities. Now, as I'm not
the maintainer of gawk (nor of tawk) I'm afraid I won't change
a line of code in it ;D)