Re: about the local not-on-every-function-separately var issue

[Eli Schwartz]

On 3/22/21 9:38 PM, Dale R. Worley wrote:
> Greg Wooledge <greg@wooledge.org> writes:
>> Now, the big question is WHY you thought something which is not correct.
>>
>> The most common reasons that people think something which is wrong are:
> 
> In my experience, a common reason is that the documentation does not
> concentrate in one place that users are certain to read, a complete,
> clear description of the situation.  For instance, you give a complete,
> clear description:
> 
>     Bash uses "dynamic scope" when it expands variables.  This means that
>     it looks first in the current functions local variables; if the variable
>     isn't found there, it looks in the caller's local variables, and then
>     in the caller's caller's local variables, and so on, until it reaches
>     the global scope.
> 
> And that behavior is implied if you read the definition of "local"
> closely.  But I couldn't find any text in the manual page that states
> that directly.

It's described pretty plainly in FUNCTIONS. It even mentions dynamic
scoping as an explicit term.

"Ordinarily, variables and their values are shared between the function
and its  caller. If a variable is declared local, the variable's visible
scope is restricted to that function and its children"

It also finishes off its description by pointing out "When the function
returns, the global variable is once again visible."

> (*Very* closely, as the text refers to "the function and
> its children".  But function definitions don't nest; what it means is
> "the function *invocation* and its child invocations.)

Since you yourself felt the need to describe this as "nested" functions,
not "child" functions, I'm curious why you thought nested functions as a
source code paradigm is a better comparison than, say, parent/child
processes as an invocation paradigm?

python has nested functions. If I ever heard someone refer to a child
function in python, I would not expect it to refer to nested functions
-- I'd expect it to refer to the call stack.

Going back to the previous definition I pointed out... note the explicit
comparison of "caller" and "children" as opposites.

>  In principle it
> should be stated at the point where parameter expansion is introduced,
> as it is the *definition* of what parameter expansion does.

I don't see what principle makes you think it should be removed from its
current location, the description of functions (which is extremely
relevant to function scoping) and moved to parameter expansion, which is
currently all about the syntax rules non-local and local variables share.

Which is still not the location where local is defined and described.


-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

OpenPGP_signature
Description: OpenPGP digital signature