Why we will use obj$func() often

[Bengt Richter]

On Sat, 24 Apr 2004 09:46:54 -0700, "Michael Geary" <Mike at DeleteThis.Geary.com> wrote:

>David MacQuigg wrote:
>> How about instead of decorating variables with special
>> symbols or capitalization, we have a rule that says any
>> variables with unusual scope must be declared in a
>> statement at the top of the function where they are used.
>> So for example
>>
>> def func( x, y ):
>>    global   a, b, c    ### module level
>>    external d, e, f    ### one level up
>>    ...
>>
>> This would avoid the need for new and unique symbols,
>> would unclutter the code in the body of the function, would
>> provide a single place where you could see the scope of any
>> unusual variable, and would answer the question "What
>> external dependencies does this function have?"  Does it
>> satisfy the need you are seeing for & variables?
>
>Hey, that is a great idea, David. I definitely like it better than the &
>notation. It would work in Python as well as Prothon, and give me clean and
>readable closures like I have in JavaScript.
>
>I would want it to mean:
>
>    external d, e, f   # # # search up the scope chain

external has been suggested before ;-)
http://groups.google.com/groups?selm=bmdelc%24rsf%240%40216.39.172.122&rnum=25
>
>because I often want to use variables from scopes more than one level up.
>And maybe another word would be better than 'external' (although I don't
>have one in mind). But the idea is terrific.
>
>> Python added "read access" to external variables, so they
>> must have considered "write access" as well.  I don't know
>> the history, but I would guess the reason they didn't allow
>> this is the same as the reason they don't allow GOTO.  Yes
>> it is powerful, but it might encourage bad programming.
>
>We're both speculating, of course, but my guess is simply that automatic
>creation of variables by assignment conflicts with writing to variables from
>outer scopes. The global statement solves this for global variables, but no
>one thought it important enough to do something for nested scopes as well.
>Just my guess.
>
I think if we break down the uses of names, separating the determination of what
namespace they belong to from lookup and binding operations, we can identify some
simple possibilities. I.e., for
    a = b
the current rules (which can't change w/o code breakage) are first of all different
for the left and right side of the '=':

On the left, it always means the local namespace, unless declared global. And it
always means bind, whether a current binding exists or not.

On the right, unless declared global, it means search the chain of scopes[1]
and find the existing binding (or raise an exception if none).

The problem is binding and rebinding in external scopes. IMO limiting that just
to _re_binding would not be a serious limitation, and then we would only
need a simple spelling for find-in-the-chain-of-scopes-and-rebind. I would suggest
   a := b
to mean that. I.e., find b as usual, then find a as if it were on the right
(raising an exception if not found), and rebind it in the namespace where it was found.

Then Mark's example would be written simply as

   def getFunc():
       counter = 0
       def count():
               counter := counter + 1  # or perhaps counter +:= 1
               print counter
       return count

[1] BTW, "external" scopes could be defined in more general ways than only lexical scoping.
E.g., IIRC postscript lets you push (and pop) dictionaries on a stack, and bare names are
searched for through that. It might be interesting to be able to push a dictionary to work
like a new local namespace without the control stack being changed. To get really general,
you could dynamically define an explicit sequence of name spaces in some kind of ns path
analogous to sys.path. ... just BF'ing ;-)

Hm ... more: what about applying find-and-rebind to an mro path? Thus
    self.classvar_or_instvar := 123
could rebind a class variable unless shadowed by an instance variable.
This would be a concise way of getting to a class variable without using
the global class name, and an easy way to share a variable amongst instances.

Regards,
Bengt Richter