Re: feature request, vars local only to function running, not sub functions running

[Koichi Murase]

2021年5月13日(木) 17:56 Alex fxmbsw7 Ratchev <fxmbsw7@gmail.com>:
> good question yo what would it print then.....
> i guess as i dont know ( you know, when thinking what should it print,
> conflicts come ) i also cannot keep the feature request alive :/ :)

If we can determine a well-defined behavior, we may still consider the
lexical scoping.

Perl is one of the languages in which both dynamic and lexical scoping
coexist. One can declare a dynamically-scoped variable by "local
$var", and a statically-scoped variable by "my $var". I don't
particularly use Perl so much, but according to Sec. 4.8.4 in
https://docstore.mik.ua/orelly/perl/prog3/ch04_08.htm , it seems the
dynamic scoping of Perl behaves like a temporary value of the global
variable. This means that the example in my previous email (rewritten
in Perl) will output "dynamic" in Perl. Maybe someone on this mailing
list who is familiar with Perl has additional comments.

https://lists.gnu.org/archive/html/bug-bash/2003-02/msg00075.html
19 Feb 2003 09:03:42, Chet Ramey
> `POSIX' functions (name()) have no scoping at all.  Your test will print
> `0 0'.  `ksh' functions have lexical scoping.  Your test will print `15 15'.
> Just to make things more complicated, ksh allows lexically-scoped variables
> to be exported in the environment, in which case they act as if they're
> dynamically scoped.

As described by the above reply, ksh93 is by default lexical scoping
in ksh-functions ("function func { ... }" form), but it seems the
values of the exported variables would propagate to the
automatically-defined lexically-scoped local variables in the callees.
I tried ksh93, it turned to print an empty string with the example in
my previous email (rewritten in ksh). This is simply confusing and
unintuitive. This is a bad example. I think we shouldn't follow ksh.

--
Koichi