Python's Lisp heritage

[Christopher Browne]

> On Mon, 2002-07-15 at 15:35, Christopher Browne wrote:
> > If a new Emacs mode requires adding in a bunch of additional
> > parameters, dynamic scope lets them be visible throughout the scope
> > during which they are "live" as opposed to just within the environment
> > in which they were defined.
> [snip]
> > If all you have is lexical scoping, parameters have to get explicitly
> > passed down the chain in order to get from function A to function C.
> > That means introducing additional parameters to function B, which
> > didn't actually care about those extra values.

> Interesting argument.  I think that you can achieve similar results
> with big state-holding objects (for better or worse).

Agreed.

Thinking of the Emacs context, from which this comes, if Emacs were
implemented using something nearer to Common Lisp, with an object
system more like CLOS, it would certainly be possible to attach extra
"slots," as needed, to the "big state-holding object."

That might very well be more manageable.

> With a web framework, that might be the request object.  Or in an
> editor in might be a buffer object.  If you have an object that
> persists for about the same scope as you need this extended
> information, you just set an attribute on that new object (or use a
> mix-in or some other technique).  Then, in your extensible
> application, this object gets passed around (perhaps indirectly) to
> most functions and methods that would be extensible.

I think that nicely characterizes the little bit of dilemma that is
involved.

Dynamic scope addresses the issue of "well, this shouldn't _really_ be
global data, but it's not as local as we'd like."

When that comes up, you've definitely hit something that's messy.

Dynamic scope tries to attach the data to the "overall scope of the
code," which is definitely extremely nebulous to try to grasp.  In
effect, the data gets tied to the environment; it works, but has
considerable risk of confusion, particularly because the data isn't
tied to anything that forcibly has an identity.

Attaching the data to "some big, state-holding object" is an approach
where, well, "it's using an object."  

In this context, the crucial definition of "object" is the classical
one that an object is a thing with an identity.  "Somewhere in the
environment" is certainly NOT an identity :-).

> This does kind of defeat lexical scoping, though it avoids use of
> globals.  While function signatures don't change, it's at the
> sacrifice of object interfaces.  OTOH, it seems to work okay.

I'd contend that there's no "defeat" involved.  This isn't a "battle"
with "winners" and "losers;" it's a situation of Trying to Solve
Problems.
--
(concatenate 'string "cbbrowne" "@ntlug.org")
http://www.ntlug.org/~cbbrowne/sap.html
Did you  hear about the dyslexic  agnostic insomniac who  stays up all
night wondering if there really is a Dog?