🚀 go-pugleaf

bh@anarres.CS.Berkeley.EDU (Brian Harvey) writes:
>The responses are talking about the case in which you've (foolishly) used the
>same name for two different variables in different scopes.

I guess I just don't see that this usage is foolish.  For example, you can take
the "animals" guessing program, which presumably builds up its database in
global variables, but put a wrapper around it of a procedure which declares its
own database variables, and in this way create a local animals database in
addition to the global one, without modifying the original animals program
(i.e. using it as a library package, which is good).

[good stuff about dynamic scope deleted]
>It also means that you can have "semi-global" variables that are local
>to the top-level procedure of a program, usable throughout that program,
>but not cluttering the workspace for the next program (or the next
>invocation of this one).  That offends Software Engineers, but it's
>damned convenient.

I don't know about this offending Software Engineers.  I learned in Software
Engineering that restricting the scope of values and variables and procedures
as much as possible was good, and that programming languages which gave you the
ability to produce intermediate levels of scope size were therefore good.  This
is the reason that modules are said to be good, isn't it?


Also, rrogers@cs.washington.edu (Richard Rogers) writes:
>If I understand your comment, I think it's incorrect.  If this is the situation
>you are talking about:
>
>global variable A
>
>procedure X
>   local variable A
>
>   local procedure Y
>         access A
>   end Y
>
>end X

No, my example was without the enclosing procedure Y.  Simply with a global
variable A, and:
	to one
	    local "A
	    two
	end

	to two
	    ... reference to :A ...
	end

When "two" is called from "one",  the meaning of ":A" is different for lexical
and dynamic scoping, but points to a variable each time.