Why we will use obj$func() often

[David MacQuigg]

On Fri, 23 Apr 2004 23:07:47 -0700, "Mark Hahn" <mark at prothon.org>
wrote:

>You aren't the only one who thinks that closures are unnecessary.  Dave
>McQuigg has posted several messages today making that argument.  I also have

Please be more careful about characterizing what other people say.  On
this thread alone you have stated or implied that others are attacking
you personally, or are prejudiced, or are taking some position that
they are not.  I have *not* argued that closures are unnecessary.

>several people saying they couldn't live without them.  One javascript
>programmer says he uses instance variables for access outside of objects
>(properties) and closure variables for storage variables inside objects.  He
>has posted a lengthy messge about it on the Prothon lists.  Go figure.

I figure that it depends on what language you have been using.  Python
has other mechanisms to provide the functionality of closures, so
Python programmers don't feel the need.  Other languages may depend
heavily on closures.  By "closures" I mean access to variables outside
the scope of the current function.

>I personally think the complications of adding one '&' prefix to give all
>the benefits of closures is a good trade-off.  No matter how much people
>rant and rave about Prothon heading down the path to the Perl-y gates of
>hell (sorry about that pun) I refuse to believe that some ugly punctuation
>is going to ruin an otherwise good language.

The problem is not the ugly punctuation.

We need to understand what you mean by "all the benefits".  The
example you posted could be done more easily and more transparently
using existing mechanisms in Python.  Even extrapolating that example
to a larger program doesn't show a benefit.  {Note: this is a
statement about the example, not about closures in general.}

>> I might seriously
>> consider what I believe we call lexical scoping, and a declaration -
>> not assigning a type, but an initial value, like "let x = 0".
>> Namespaces like Python's would be for objects - modules, classes,
>> class instances, whatever - not functions - and would be purely
>> explicit, not implicit like a scope (I think that would most
>> conspicuously require some alternative for "def" statements,
>> for example.)
>
>I'm not following you exactly, but I think what you are asking for is the
>declaration of variables with "let x = 0", or what some languages use is
>just "var x" that specify that the variable belongs in the scope of that
>declaration.  This resolves the ambiguity of local versus global variables
>and even gives a nice solution for closures.

I think what he is suggesting is that functions not have their own
namespaces.  This seems like overkill to me.  Maybe we could have a
special kind of function that shares its namespace with the block in
which it is embedded -- an "inline" function -- basically a block of
code that can be invoked with one statement.  This might be worth
proposing.

>That is an interesting idea.  It turns out to be a little harder for the
>compiler and program reader to use because both have to still scan the code
>to find that declaration and discover what scope a variable belongs in,
>although it is much easier than the current Python scheme where there are
>complex rules and more code scanning involved, but less typing.  The Python
>intrpreter requires three scans to parse the source and generate bytecodes.
>
>The advantage of prefix symbols that Ruby and Prothon use right now is that
>the compiler and the program reader don't have to scan the code at all to
>see what scope the var belongs to.  When you see the & you know it's in the
>surrounding function, when you see a capital letter you know it's global to
>the module, when you see a lower-case letter you know it's local, etc.  Once
>you get used to it the code is much more readable.  The Prothon compiler
>parses source and generates code in one fast pass.

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?

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.  

Can you imagine having to debug a large program where none of the
functions have any arguments, just &vars buried in the bodies of the
functions?  That is the kind of code that might be written by someone
who does not want to think ahead.  You can write the call() first,
then use & variables whenever you need an argument.  These are the
kind of things that must be considered when looking at a new feature
for a language.

-- Dave