Why we will use obj$func() often

[Mark Hahn]

It can, if you spell '&' differently:

def getfunc():
def count (n=[0]):
n[0] += 1
print n[0]
return count

c = getfunc()
c()
c()
c()

True. A bit inelegant, but then so is &.

Would you trade the "mutable integer" and "count(n=[0])" kludges for a
solution like &count ? Does anyone agree with me that a "closure variable
prefix" is more explicit and readable?

Let's seperate the aesthetic issues of using "Perl-like" symbols from the
"closure variable prefix" functionality for a moment. I'd like feedback on
both issues, but try to keep them seperate.

 

[Peter Hansen]

Peter: You were making fun of how of fast I'm changing things in Prothon,
right? I was going along with that humour in my message. Someone in a
private message accused me of making fun of you, which I was definitely not
doing.

No offense taken, nor thought to be intended. (Best to include
a smiley next time, however, just in case. I think the newsgroup
needs more of those right now. I think it's those damn crows outside
my window that are getting everyone on edge. You can hear them,
right? They're very loud... where's a kid with a BB gun when you
need him?)

-Peter

 

[Peter Hansen]

Mark Hahn wrote:
...
Ah, too bad, you might have fit in if you did . He's just *so* much
fun to poke fun at. For crimminy's sake, he's from Canada, and you know
how ridiculous they all are... blubber-eating igloo-wardens every last
one of them. It's practically impossible to take one of them seriously
as a computer programmer, I mean, really, a modern computer would just
melt the igloo down around their heads.

See you downtown at the PyGTA meeting on Tuesday, Mike. And remember
your snowshoes this time, for heaven's sake. It's still *April*, for
cryin' out loud!

-Peter

 

[Peter Hansen]

Well I have a problem now. I gave people on my mailing list a choice
between $var, `var, ~var, and ^var. The current tally is four votes for
$var and none for any of the others. According to your criteria, $var is
the worst and ~var should be the best. Am I correct?

If I recall correctly, ObjectRexx uses ~ the way Python uses . (dot).
I wasn't really partial to it, but it didn't really stand in the way
of writing or reading the code.

I have to go with Mike on the problem with $ however...

 

[Mark Hahn]

connection = serial.Serial ( ... )
# connection is a file-like object,
# having the usual `write` method

engine = MyFiniteStateMachine ()
# engine happens to have a `writer` method that
# funnels out the machines products
# The default is effectively `def writer (self, s): print s`

engine.writer = connection.write
# we channel engine's output through the serial connection

Plugged together, it just works, as Mike says. No
trouble when engine's internal calls to `self.writer` end up
accessing a completely different object's method. It's only
lately that I've stopped to gawp at it, and wonder.

That is a powerful testimonial to the "walks like a duck" principal which
has nothing to do with classes or prototypes. Thankfully that works in a
simple classless language like the current Prothon.

 

[Mark Hahn]

I have to go with Mike on the problem with $ however...

I think he makes sense also, which means my democracy is in trouble. I put
it out for a vote and everyone is voting for $. I should have figured this
would happen. More people use Perl than Python also (Just kidding -- no
flames please -- just kidding).

 

[David MacQuigg]

Yes, it's a tie in this example. There are many cases however where you are
already in a situation where you have a function and the closure is
beneficial and creating a "class" would be unneeded overhead. I don't
really have the time to create something large enough here to demonstrate
it. You'll just have to take my word for it (or not).

It's a tool for your toolchest and it's the kind of thing that if your not
familiar with it you'll never miss it, but once you learn it and use it a
few times you'll wonder how you ever lived without it. Also I can drag out
the old tired argument that if the closure bothers you "you don't have to
use it".

I appreciate that I may be missing something important because it can
only be seen in a larger example. For many years I scoffed at C++
thinking I could do anything I needed without OOP.

Still, the question of whether we should include special syntax for
closures is an important question that deserves some time on a
use-case before even putting it into Prothon, let alone expecting
Python users to learn it.

I'm not seeing the "overhead" of classes that you refer to. To me, a
class is very lightweight thing. I use nested classes, for example to
store hierarchies of variables, like
window1.plot2.xaxis.label.font.size = 12

It is quite alright to show a small example and expect us to
extrapolate to something 100 times larger. Even if we extrapolate the
example above, however, Python still wins.

I don't like the "toolchest -- don't have to use it" argument, because
that could be used to justify *any* added syntax, and I really like
the compactness of Python. The more overlapping features we have, the
more confusion there will be in reading someone else's programs, for
example.

I don't like the "once I learn it argument" either. An equally valid
argument is that people who have developed a *habit* in other
languages of using closures, are now unnecessarily dependent on them,
and will have to learn simpler techiques to get by in Python.

By the way, if we work on the example a little, Python wins on
transparency *and* codesize.

class A:
count = 0
def bump(self):
A.count += 1
print A.count

c = A().bump
c(); c(); c()

-- Dave

 

[Donn Cave]

It can, if you spell '&' differently:

def getfunc():
def count (n=[0]):
n[0] += 1
print n[0]
return count

c = getfunc()
c()
c()
c()

True. A bit inelegant, but then so is &.

Would you trade the "mutable integer" and "count(n=[0])" kludges for a
solution like &count ? Does anyone agree with me that a "closure variable
prefix" is more explicit and readable?

Let's seperate the aesthetic issues of using "Perl-like" symbols from the
"closure variable prefix" functionality for a moment. I'd like feedback on
both issues, but try to keep them sep~rate.

I don't think a closure variable prefix sounds very good.

What you're doing there looks to me a bit like Objective
CAML's ref type. "a = ref 0" is a mutable container for an
immutable integer. It's just syntactic sugar for a mutable
record; the sugar is the assignment a := 1, and then there's
some special dereference notation -- a := !a + 1, something
like that, I forget.

There could be a case for a mutable-container-of-one-item
type in Python, with or without special syntax. Without
the syntax, it's still mildly interesting because it expresses
intent - both to the human reader, and to other software
components which should not be invited to delete or add
items etc.

class Ref:
def __init__(self, a):
self.value = a
def __setattr__(self, a, v):
if a == 'value':
self.__dict__['value'] = v
else:
raise AttributeError, a

var = Ref(0)

var.value = var.value + 1


I personally think syntactic sugar wouldn't add any real
value to that, but that just seems to be one of those
matters of taste, where some people like languages like
Pe... oops.

Donn Cave, (e-mail address removed)

 

[Mark Hahn]

What you're doing there looks to me a bit like Objective
CAML's ref type. "a = ref 0" is a mutable container for an
immutable integer. It's just syntactic sugar for a mutable
record; the sugar is the assignment a := 1, and then there's
some special dereference notation -- a := !a + 1, something
like that, I forget.

I'm not doing anything nearly that complex. &var just gives access to the
outer closure scope and directly accesses var in that scope, just like
accessing a global variable. It isn't just syntax sugar for var[0] because
it has none of the list overhead associated with the var[0] kludge. & just
tells the compiler where to find the variable, just like capitalized
variables in Prothon say to find them in the global space and .var says to
find var in self.

The whole point is to make things simpler, more readable, and more
efficient, but when people see the & symbol they somehow automatically think
it's complex. Maybe my mind doesn't work like everyone else's.

 

[David MacQuigg]

It can, if you spell '&' differently:

def getfunc():
def count (n=[0]):
n[0] += 1
print n[0]
return count

c = getfunc()
c()
c()
c()

True. A bit inelegant, but then so is &.

Would you trade the "mutable integer" and "count(n=[0])" kludges for a
solution like &count ? Does anyone agree with me that a "closure variable
prefix" is more explicit and readable?

Let's seperate the aesthetic issues of using "Perl-like" symbols from the
"closure variable prefix" functionality for a moment. I'd like feedback on
both issues, but try to keep them seperate.

We need to see what the problem is before we can judge a solution.
Just showing a code snippet and saying "do this" is not a good
statement of the problem. As you have seen, there are simple elegant
solutions that don't follow your code line-for-line, and there are
inelegant solutions that are very close. Both categories seem to
solve what we think the problem is, but you may have another problem
in mind. A use-case would be helpful.

As an alternative, we could work with a clear statement of the
problem, something like: The proposed syntax will allow assigning
values to (not just referencing) variables in a scope surrounding a
nested function. This will be useful when the existing alternatives
are not appropriate:
1) Attach the variable to an instance.
2) Make the variable global.
3) Add the variable to the function argument list.
4) ...

I've probably mistated it, but you see what I'm getting at, something
that de-couples the user-level problem from the particular mechanisms
of the language. Trying to reproduce these mechanisms in Python will
be the road to Per ... dition. :>)

-- Dave

 

[David MacQuigg]

What you're doing there looks to me a bit like Objective
CAML's ref type. "a = ref 0" is a mutable container for an
immutable integer. It's just syntactic sugar for a mutable
record; the sugar is the assignment a := 1, and then there's
some special dereference notation -- a := !a + 1, something
like that, I forget.

I'm not doing anything nearly that complex. &var just gives access to the
outer closure scope and directly accesses var in that scope, just like
accessing a global variable. It isn't just syntax sugar for var[0] because
it has none of the list overhead associated with the var[0] kludge. & just
tells the compiler where to find the variable, just like capitalized
variables in Prothon say to find them in the global space and .var says to
find var in self.

The whole point is to make things simpler, more readable, and more
efficient, but when people see the & symbol they somehow automatically think
it's complex. Maybe my mind doesn't work like everyone else's.

I think you are misunderstanding the objections to the proposed
features. I see on this thread very little knee-jerk reaction to a
new symbol. Its the accumulation of symbols and special syntax for
little problems that will cause a big problem. In my first post on
this thread I pointed out the problem:

-- Perl-like syntax:
Special symbols and capitalization to indicate variable scope,
closures, dynamic variables, etc.
local, Global, .x, ^x, X, &x, x, @x

Yes, I did use the P word, but my criticism is *not* over the choice
of symbols. What I worry about is the complexity which will result
when all these little features become commonly used, and students are
accessing variables all over the place instead of thinking about the
structure of their programs, and figuring out how to solve a problem
with simple syntax and structures.

Once you add something like &x to a language, you can never take it
out. Not only will you break existing code, but you will break the
hearts of all those who now cannot write a program without that
feature.

I'm not trying to give you a hard time. I just don't see the value in
providing elegant syntax for obscure problems like &x. I'm not saying
the value isn't there. I just don't see it in what you have posted so
far, and I'm a bit put off by your statement that you don't have time
to put together a use-case.

If I were you I would postpone all these embellishments, and the
associated discussions, and focus on the one really good thing in
Prothon, your simplification of classes. If you can do that in a way
that doesn't make migration from Python difficult, you will have a
winner.

-- Dave

 

[Donn Cave]

Quoth "Mark Hahn" <[email protected]>:
....
| ... & just
| tells the compiler where to find the variable, just like capitalized
| variables in Prothon say to find them in the global space and .var says to
| find var in self.
....
| The whole point is to make things simpler, more readable, and more
| efficient, but when people see the & symbol they somehow automatically think
| it's complex. Maybe my mind doesn't work like everyone else's.

It may be one the language inventor's perils - hard to communicate
with people in a language you just invented for the purpose!

To me, if you want simple - this counter closure thing is done
better with an object. It's weird, unnatural and sounds like
an implementation headache to support persistence in a function
local variable namespace. I don't know if Python does that
already, but that wouldn't make it any better. When I want
a thing with persistent data, I'm thinking of an object. One
must keep things simple.

I think if I were writing a language from scratch, one that's
vaguely similar to Python but not especially, 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.)

Donn Cave, (e-mail address removed)

 

[Mark Hahn]

When I want
a thing with persistent data, I'm thinking of an object. One
must keep things simple.

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
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 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.

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.

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.

I'm sorry, I got into sales pitch mode again. I'll let you go. It's been
interesting chatting...

 

[Michael Geary]

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 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'm the JavaScript programmer.

I would never say I couldn't live without closures--I don't think I've seen
a situation where they are the only way to get the job done. But I do find
that they provide a very clean and natural way to do some things.

One problem with talking about closures is that silly counter example that
we all come up with when we need to demonstrate their use. Even closure fans
like me use that same example for some reason--it must be a law or
something. The trouble with that example is that there's not really much
benefit to the closure there. (Just an observation: The arguments I'm seeing
against closures are coming from people who haven't used them in situations
where they are beneficial.)

One place I've been finding closures to be a clean, elegant solution is in
Acrobat multimedia JavaScript code, especially in event listener methods. I
developed the multimedia JavaScript API in Acrobat 6, and naturally I had to
eat my own dog food and develop a number of sample multimedia PDF files.
(You can find one of them at www.mfiles.co.uk - scroll down to the Animated
PDF Sheet Music section.)

Here is some Acrobat multimedia code written with and without closures.
(Sorry to use JavaScript as an example, but I don't have any real life
Python or Prothon code with closures handy. This should serve to illustrate
the concept, though.)

We'll define a function "reportScriptEvents( reporter )" which plays a media
clip and listens for any Script events that the media clip fires. It
accumulates the text of those Script events in a log string, and when the
player closes, it calls the 'reporter' function and passes it that string.
This is done using event listener methods which are called during
playback--after reportScriptEvents returns.

Here is the reportScriptEvents function and a testReport function which
provides a reporter that pops up a message box when the player closes:

function reportScriptEvents( reporter )
{
var log = "";

app.media.openPlayer(
{
events:
{
onScript: function( e )
{
log += e.media.command + ': ' + e.media.param + '\n';
},

afterClose: function()
{
reporter( log );
},
},
});
}

function testReport( title )
{
reportScriptEvents( function( log )
{
app.alert({ cTitle: title, cMsg: log });
});
}

testReport( 'Here are the script events' );

To me this is very clean and simple. I don't have to think about the fact
that the onScript and afterClose functions are called long after
reportScriptEvents returns, or the fact that the anonymous reporter function
inside testReport is called after testReport returns. I don't have to create
an object or any kind of machinery to hold these persistent variables. They
just work.

As an alternative without the closures, I can take advantage of the fact
that we pass the media player object into the event methods:

function reportScriptEvents( reporter )
{
var player = app.media.createPlayer();
player.myLog = "";
player.myReporter = reporter;

player.events.add(
{
onScript: function( e )
{
e.media.player.myLog +=
e.media.command + ': ' + e.media.param + '\n';
},

afterClose: function( e )
{
e.media.player.myReporter( e.media.player.myLog );
},
});

player.open();
}

This is quite a bit messier. I have to know more about the details of what
Acrobat passes into event listeners (the e.media.player.* business). And I
still have to come up with something to substitute for the closure in the
testReport function.

Maybe there is a more elegant solution, but it's past midnight and the
margin of my brain is too small to contain it. Closures make this kind of
code so simple that I can understand it even at this late hour.

-Mike

 

[David MacQuigg]

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'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

 

[Michael Geary]

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

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.

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.

In JavaScript, I often use nested functions to factor out common operations
within a function--things that are done repeatedly inside that function but
aren't of interest outside the function. Lexical scoping lets me do that
without the nuisance of passing in the same arguments to all these nested
functions, or creating some little object for that purpose. I could post
some sample code if anyone wants, but I fear I may have posted too much
JavaScript code here already. But the point is that I use this very
thing to make my code simpler and more readable.

-Mike

 

[Donn Cave]

Quoth "Mark Hahn" <[email protected]>:
....
|> 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.

The declaration is probably the most trivial part of it. The notation
could be omitted - may as well, since "x = 0" would be implicitly the
the same as "let x = 0" anyway. The point is that scope is purely
lexical, defined by source structure - top to bottom, left to right,
outside to inside.

My hunch is that this would be less confusing, especially multiple
nested scopes are no problem with lexical scoping. It should also
make for more efficient execution, because compiler/interpreter is
looking at the complete story on what's what. For example, you can
have true global constants, a common programming notion that Python
doesn't support.

It would be fatal for closures of the counter type, because that
takes a runtime binding somewhere. This would be legal code -

mkCounter = function ():
i = 0
countup = function ():
i = i + 1
print i
return countup

.... but the countup function would always print "1". You'd need
an explicit function namespace, like -

mkCounter = function ():
countup = function ():
.i = .i + 1
print .i
countup.i = 0
return countup

.... but maybe this is where we realize that this functionality
belongs to objects.

Donn Cave, (e-mail address removed)

 

[Bengt Richter]

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/[email protected]&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.


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

 

[Paul Prescod]

...

My biggest problem right now is stupid aesthetics. I have to decide where
to place Prothon on the continuum between lisp and perl. When I crossed the
line and added $ for self people screamed bloody murder that it looked like
Perl. Before when I had a period for self they thought it looked great. I
can't believe how much they care about something so silly.

Yes, people are irrational. But if you care about language popularity
you have to take that into account. Else you end up with a language that
never goes mainstream like Lisp.

Paul Prescod

 

[Paul Prescod]

...

My biggest problem right now is stupid aesthetics. I have to decide where
to place Prothon on the continuum between lisp and perl. When I crossed the
line and added $ for self people screamed bloody murder that it looked like
Perl. Before when I had a period for self they thought it looked great. I
can't believe how much they care about something so silly.

Yes, people are irrational. But if you care about language popularity
you have to take that into account. Else you end up with a language that
never goes mainstream like Lisp.

Paul Prescod