🚀 go-pugleaf

There are two different issues about scoping.  I was trying to address one,
and the responses are addressing another, and that's why there's this
confusion, I think.

The responses are talking about the case in which you've (foolishly) used the
same name for two different variables in different scopes.  You have a global
variable X, and you have a local variable X in procedure A, and now along
comes procedure B making a free reference to X.  Clearly it can only get at
one of those Xs, not both, no matter how you slice it.  If procedures A and B
are defined separately (as they always are in Logo, except Object Logo) and
procedure A invokes procedure B, then lexical scope says you get the global X
but dynamic scope says you get the local X.  The message objecting to my
original message was correct about that.

But I wasn't thinking of the case of name conflicts.  Instead, I was thinking
about the situation in which all variables have distinct names.  In that case,
as I suggested, the variables available to procedure B under lexical scope
are a subset of the ones available to it under dynamic scope.  Under lexical
scope it has the free variables and its own variables; under dynamic scope it
also has those of procedure A.

This situation is in contrast with what happens in Scheme, where lexical
scope sometimes gives you access to extra variables, namely, when you use
a procedure that was defined inside another one, like this:

(define (make-adder n)
  (lambda (x) (+ x n)))

((make-adder 3) 5)    ====>   8

This wouldn't work with dynamic scope because when the function returned
by (make-adder 3) is invoked on the argument 5, it wouldn't have access
to the variable n that it needs.

But Logo doesn't have lambda, and so lexical scope merely restricts the
available sources of variables.  (Same in C and Pascal.)

About debugging:  It's true that dynamic scope introduces the possibility
of unexpected name conflicts.  That can be a source of bugs, especially if
you're working on an immense programming project with a bunch of other
people, so two members of the team can use the same name without each
other's knowledge.  But nobody uses Logo for huge software engineering
projects anyway!  My experience is that "name captures" are pretty rare
when one person is writing a bite-size program.  On the other hand, what's
not rare is that you have a chain of procedure calls, A calls B calls C
calls D, and an error in A presents an incorrect input to B, which
eventually leads to a Logo error message in D.  Well, you can't debug
the problem in D unless you have access to A's variables, and that's what
dynamic scope buys you.

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.