Why we will use obj$func() often

[Mark Hahn]

"Michael Geary" <Mi**@Geary.com> wrote ...

Does anyone have some sample code where obj$func() would be used?
(Apologies if I missed it.)

There have been so many messages about delegation and binding since Greg
originally posted his meowing cat message that it's hard to remember what
the original problem was that Greg pointed out. At that time Prothon had no
solution for the problem. Now there is a released solution but it is
incomplete and has broken the xor operator ( ^ ) (don't tell anyone <grin>).
I'll restate it here in my own way (this is copied from something I posted
on comp.lang.py).

Statement of problem (These are tested programs from released Python and
Prothon:):

# Python

class klass:
def __init__(self):
self.me = 1
def func(self):
print "func1,self"+str(self.me),

class klass2(klass):
def __init__(self):
self.me = 2
def func(self):
klass.func(self) # delegation
print "func2,self"+str(self.me),

inst = klass2()
inst.func() # prints func1,self2 func2,self2

# Directly translated to Prothon

Klass = Object()
with Klass:
.me = 0 # extra line
def .__init__():
.me = 1
def .func():
print "func1,self"+.me,

Klass2 = Klass()
with Klass2:
def .__init__():
.me = 2
def .func():
Klass.func() # does not do what python does
print "func2,self"+.me,

inst = Klass2()
inst.func() # prints func1,self0 func2,self2

As you can see, the call Klass.func() got the function func from the object
Klass and then called it on Klass using Klass as the target "self" instead
of the instance "inst". This is not what Python did and this is the
problem.

In Python the call klass.func() was different because Python knows that
klass is a class and therefore obviously cannot be the target of call (an
instance), so it made the programmer pass the instance self to use as a
parameter.

To fix this, we need to be able to specify in general, what the self object
is going to be during the execution of a function in Prothon (I call this
choice of self "binding self to function" even though it's temporary during
execution).

Greg's solution was to replace the period before the function name in
klass.func() with a different symbol to indicate that the func is not
supposed to be bound to klass as the syntax normally suggests (as in
list.sort!()), but instead defaults to the current self. My final scheme is
almost the same but instead of just defaulting to self, it specifically
forces it to self (this may seem like a semantic difference, but don't say
that to Greg <grin>).

So now we have this solution. Note that delegation to an ancestor prototype
(class in Python), is a common operation, especially in the __init__
function:

Klass = Object()
with Klass:
def $__init__():
$me = 1
def $func():
print "func1,self"+$me,

Klass2 = Klass()
with Klass2:
def $__init__():
$me = 2
def $func():
Klass$func() # voila! problem fixed
print "func2,self"+$me,

inst = Klass2()
inst.func() # prints func1,self2 func2,self2

[David MacQuigg]

On Fri, 23 Apr 2004 16:36:15 -0700, "Mark Hahn" <ma**@prothon.org>
wrote:

"Donn Cave" <do**@u.washington.edu> wrote ...

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" <ma**@prothon.org>:
....
| ... & 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, do**@drizzle.com

[Mark Hahn]

"Donn Cave" <do**@drizzle.com> wrote ...

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]

Mark Hahn 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 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]

On Fri, 23 Apr 2004 23:07:47 -0700, "Mark Hahn" <ma**@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

[Michael Geary]

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

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" <ma**@prothon.org>:
| "Donn Cave" <do**@drizzle.com> wrote ...
....
|> 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, do**@drizzle.com

[Bengt Richter]

On Sat, 24 Apr 2004 09:46:54 -0700, "Michael Geary" <Mi**@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...72.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

[Paul Prescod]

Mark Hahn wrote:

...

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]

Mark Hahn wrote:

...

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

[Mike C. Fletcher]

Paul Prescod wrote:
....

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.

Oooh, lovely double entendre there... ;)

You get a smiley for that one :) .
Mike

_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/

[Paul Prescod]

Mike C. Fletcher wrote:

Paul Prescod wrote:
...

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.

Oooh, lovely double entendre there... ;)

You get a smiley for that one :) .

I wish I were smart enough to do that purposefully. ;)

Paul Prescod

[Greg Ewing]

Mark Hahn wrote:

Yes, many people are afraid to try new things. That is a shame.

It's not a matter of being afraid, it's a matter of having
enough spare time and being interested enough to learn enough
about the new language to try it out. The more different Prothon
is from Python, the greater the barrier will be to Python
people, and the fewer of them there will be that can spare the
time to dabble in it.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Greg Ewing]

Mark Hahn wrote:

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?

Not necessarily. It can be very hard to analyse these sorts
of things, since people who have an opinion tend to know what
appeals to them and what doesn't, but not why. The pattern
recognition processess involved seem to happen in a part of
the brain that's not accessible to introspection.

My feeling is that ` and ~ are too inconspicuous, $ is
too conspicuous, and ^ has the wrong sort of connotations
(it looks like it's pointing to something somewhere else,
rather than at "myself").

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Greg Ewing]

Mark Hahn wrote:

I just meant that people "pre-judge" Prothon based on it's looks.

That argument might make sense if looks were irrelevant to
the usability of a language, but they're not -- looks have
a lot to do with readability. It's probably fair to say
that readability is *all* about looks.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Greg Ewing]

Donn Cave wrote:

I remember VMS library functions like RMS$PARSE etc.
This basically goes along with the argument above - it's
a single identifier, $ is not punctuation.

Also traditional Basic with A$, B$, etc. There, too, the
$ is considered part of the name -- A was a different
variable from A$, etc.

It seems to work best when the identifier is all upper
case, though. Putting $ amongst lower-case letters looks
goofier.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Greg Ewing]

Mark Hahn wrote:

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.

The feature itself might not be complex, but it's
unfamiliar, since it's not quite like anything in any
other language they're likely to be familiar with.
So it makes learning the language a more complex
exercise, since it's one more new thing to learn.

It's also something that will be quite rarely used,
and is totally non-suggestive of its meaning, so I
expect people will be looking it up in the manual a
lot before it finally gets internalised.

On the other hand, replacing it with a keyword such
as "outer" would make it highly suggestive, to the
point where I'd wager most people wouldn't have to
look it up at all.

This is a big advantage that words have over
punctuation -- you have much more scope for choosing
one that means something to people.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Greg Ewing]

Mark Hahn wrote:

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,

Hang on a minute. Do you literally mean the immediately
surrounding function, and not one further out? In

def f():
def g():
def h():
&x = 42
h()
g()
print x

does the &x in h refer to the x in f? If it does, then I
don't see how you can deduce that in a single pass. If it
doesn't, then how do you refer to the x in f from h?

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Greg Ewing]

David MacQuigg wrote:

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.

Actually, it was more that there wasn't any single obvious
way of providing write access that blends in with Python's
"assignment is implicit declaration" flavour. Rather than
pick one at random, it was decided to just provide read
access to begin with and leave anything else to later.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Mark Hahn]

"Greg Ewing" <gr**@cosc.canterbury.ac.nz> wrote in message
news:c6************@ID-169208.news.uni-berlin.de...

Mark Hahn wrote:

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,

Hang on a minute. Do you literally mean the immediately
surrounding function, and not one further out? In

def f():
def g():
def h():
&x = 42
h()
g()
print x

does the &x in h refer to the x in f? If it does, then I
don't see how you can deduce that in a single pass. If it
doesn't, then how do you refer to the x in f from h?

You cannot. Yes it literally means the immediately surrounding function.
In your example, I can't think of any scheme we've discussed that accesses x
in function f. Python surely cannot.

I understand this is quite limiting, but it's simple. As always, I'm open to
suggestions...

[Mike C. Fletcher]

Mark Hahn wrote:

"Greg Ewing" <gr**@cosc.canterbury.ac.nz> wrote in message
news:c6************@ID-169208.news.uni-berlin.de...

Mark Hahn wrote:

....
You cannot. Yes it literally means the immediately surrounding function.
In your example, I can't think of any scheme we've discussed that accesses x
in function f. Python surely cannot.

Well, not yet, it was explicitly not implemented until something elegant
came along IIRC.
I understand this is quite limiting, but it's simple. As always, I'm open to
suggestions...

How about:

.this (surrounding scope, often an object)
..this (surrounding scope + 1, such as a module or a nested-class'
parent

Seems elegant in a certain way. The construct is reminiscent of
directory specifiers, and meshes nicely with the attribute access
syntax. Gets a little unwieldy if you're having hugely nested
constructs, but then that's already unwieldy, so more pain too them :) .

Have fun,
Mike

_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/

[Michal Vitecek]

Mark Hahn wrote:

I just meant that people "pre-judge" Prothon based on it's looks.

i wouldn't use a language whose "look" i don't like. i prefer my code
to be well readable and maintable even after a longish time. many
symbols ($,&,^, etc.) make it a big minus for me because i tend to
forget their special meaning very soon. and looking up those characters
all the time is no-go for me.

so when i saw something like 'someObject$someMethod()' and plenty of
'.a = .b + 1' it scared me right away - simply just based on the
"look" of the language.

--
fuf (fu*@mageo.cz)

[Michael Geary]

> Greg Ewing wrote:

Hang on a minute. Do you literally mean the immediately
surrounding function, and not one further out? In

def f():
def g():
def h():
&x = 42
h()
g()
print x

does the &x in h refer to the x in f? If it does, then I
don't see how you can deduce that in a single pass. If it
doesn't, then how do you refer to the x in f from h?

Mark Hahn wrote: You cannot. Yes it literally means the immediately surrounding
function. In your example, I can't think of any scheme we've
discussed that accesses x in function f. Python surely cannot.

I understand this is quite limiting, but it's simple. As always,
I'm open to suggestions...

Ouch. The way I use nested functions in JavaScript, it's essential to be
able to use names from higher in the scope chain without worrying about how
far up the chain they are.

It's not P*thonic, but JavaScript's solution for this keeps looking better
to me. When you want a local name, you create it with 'var'. When you refer
to a name, it always starts in the current scope and works its way up the
chain until it finds the name.

As with many things, there's a cost and a benefit. The cost is that you
always have to 'var' your local variables. The benefit is that nested
functions and closures become very clean and simple.

-Mike

[Donn Cave]

In article <ma************************************@python.org >,
"Mike C. Fletcher" <mc******@rogers.com> wrote:
....

How about:

.this (surrounding scope, often an object)
..this (surrounding scope + 1, such as a module or a nested-class'
parent
Now this sounds like runtime namespace lookup. Consider
def g():
print .x
def f():
x = 5
g()

That prints 5, right? Not, I suppose, but that's how object
"scope" works. Nested function scope is at least to some extent
inherently lexical, the way we normally expect it to work - you're
referring to outer code blocks, not just any caller's namespace.
Seems elegant in a certain way. The construct is reminiscent of
directory specifiers, and meshes nicely with the attribute access
syntax. Gets a little unwieldy if you're having hugely nested
constructs, but then that's already unwieldy, so more pain too them :) .

I still think elegant is not possible when this lexical notion
of scope is bolted onto a runtime namespace lookup system (dynamic
scope.) (I cringe with fear when I use these terms, but I swear
I did look the Lisp definitions up.)

Consider
def f():
x = 5
def g():
print x
x = 7
return g
t = f()
t()

Does it print 5 or 7? Of course, we know it's going to be 7,
because we understand this system and know how to use it, but
I'm saying this is perverse in terms of what people ought to
need to understand. (I also think it's an unfortunate feature
to have to support, if it means preserving f()'s entire local
scope dictionary for the lifetime of t.)

But I admit my approach might not allow what I imagine people
would expect in places, either. Suppose in the above, f invoked
g instead of returning it. Then (I think) many would want x to
be 7 in g. My `until a better idea comes along' response would
be `too bad, use a function parameter', and I can talk about the
value of this attitude towards programming, but I don't have
enough charisma to make it popular. Similarly, I would certainly
not allow any function to rebind variables in the caller.

Donn Cave, do**@u.washington.edu

[Mark Hahn]

"Michael Geary" <Mi**@DeleteThis.Geary.com> wrote

It's not P*thonic, but JavaScript's solution for this keeps looking better
to me. When you want a local name, you create it with 'var'. When you refer to a name, it always starts in the current scope and works its way up the
chain until it finds the name.

Maybe there would be some way to make the "var" keyword totally optional.
But then that still destroys the "no need to look around to to read the
code" principle.

[Greg Ewing]

Mark Hahn wrote:

You cannot. Yes it literally means the immediately surrounding function.
In your example, I can't think of any scheme we've discussed that accesses x
in function f. Python surely cannot.
Python can't write to it, but at least it can read it.
Prothon apparently can't even read it.
As always, I'm open to suggestions...

I can't think of any way to fix this that preserves the
single-pass requirement, short of introducing some kind
of declaration in the scope where the variable is defined.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Bengt Richter]

On Mon, 26 Apr 2004 15:10:22 +1200, Greg Ewing <gr**@cosc.canterbury.ac.nz> wrote:

Mark Hahn wrote:

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.

The feature itself might not be complex, but it's
unfamiliar, since it's not quite like anything in any
other language they're likely to be familiar with.
So it makes learning the language a more complex
exercise, since it's one more new thing to learn.

It's also something that will be quite rarely used,
and is totally non-suggestive of its meaning, so I
expect people will be looking it up in the manual a
lot before it finally gets internalised.

On the other hand, replacing it with a keyword such
as "outer" would make it highly suggestive, to the
point where I'd wager most people wouldn't have to
look it up at all.

This is a big advantage that words have over
punctuation -- you have much more scope for choosing
one that means something to people.

The word "locals" already exists. If it returned a namespace
object instead of a dict proxy when given a nesting-level arg, we
could write

def f():
x = 123
locals(0).x = 123 # synonym
print x # 123
def g():
x = 456
print x # 456
print locals(1).x # 123
locals(1).x = 789
locals(2).x = 101112
print x # 123
g() # 456 then 123
print x # 789
g() # 456 then 789

print x # 101112

exec-ing or eval-ing 'locals(n)' could return a proxy object that would work
like the current proxy dict (i.e., a read-only snapshot except if it happened
to access globals()).

I suppose you could do a declarative form by giving global (or extern or outer)
a nesting level too.

Hoever, I think lhs := rhs as a spelling of find-and-rebind-lhs would cover
most use cases. (Requiring existing and lhs to have been defined first by
some lhs = rhs in the current or some lexically enclosing scope).

You couldn't reach locally shadowed outer variables of the same name, as you could
with locals(n).name, but how often do you really want to do that? Of course,
locals(n) and global/extern/outer(n) and := could be all be implemented.

Regards,
Bengt Richter

[Mark Hahn]

Greg Ewing wrote:

On the other hand, replacing it with a keyword such
as "outer" would make it highly suggestive, to the
point where I'd wager most people wouldn't have to
look it up at all.

What do you mean by keyword? Which do you mean?

1) outer x # x is declared to come from outer scope

2) outer.x # outer is prefix replacing &

Form 1 is very non-P*thonic. I was happy to get rid of the global keyword
and I'd hate to see this one show up.

Form 2 would cause more confusion than &var because the reader would just
think it was a local variable and not even think to look it up. At least
the &var would signal that something unusual was happening.

Is there a third usage you mean that I'm missing?

[Greg Ewing]

Mark Hahn wrote:

What do you mean by keyword? Which do you mean?

1) outer x # x is declared to come from outer scope

2) outer.x # outer is prefix replacing &

Form 1 is very non-P*thonic. I was happy to get rid of the global keyword
and I'd hate to see this one show up.

I was thinking of it as a direct replacement for &,
so that instead of

&x = y + &z

you'd write

outer x = y + outer z

But if you don't like the look of that, there's
nothing more to be said.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Mark Hahn]

Greg Ewing wrote:

outer x = y + outer z

It's not that I don't like the looks, it's just that I've never seen a
keyword used that way before in Python, have you? I think that would be a
big change for such a small usage case.

My symbol usage is a big change also, but consistent across the board. If
we made that change, one could argue we'd need to do the same replacement
for all my symbols. So we'd be looking at things like this?

outer x = y + global Cmp(global MAX_HGT, h) + self x
move(self ofsx, self ofsy)
if global Cmp(a,b) < 0:
self z = global Z_MIN + outer firstZAttr

I think this would make the language very unwieldy. This is kind of like
Cobol,. the opposite of Perl. Don't you agree?

I guess the whole problem is my insistence on simple scope indentification
by looking at the variable. It causes the var to need to be tagged.

I feel strongly that the Python mixture of declaration (global), default
(where assigned) and broken (closures) is broken overall and has to be fixed
in Prothon. I take this as a given. So I see these possible solutions:

1) My Ruby-like symbols, which I think are readable and fast-compilable.

2) Word-like symbols, which are large, less readable (too me) and
cluttering.

3) Declarations, which cause the compiler and user to look around and are
not Pythonic.

Am I missing any other solutions?

[Michele Simionato]

"Mark Hahn" <ma**@prothon.org> wrote in message news:<5vJjc.13116$Qy.1954@fed1read04>...

I feel strongly that the Python mixture of declaration (global), default
(where assigned) and broken (closures) is broken overall and has to be fixed
in Prothon. I take this as a given. So I see these possible solutions:

1) My Ruby-like symbols, which I think are readable and fast-compilable.

2) Word-like symbols, which are large, less readable (too me) and
cluttering.

3) Declarations, which cause the compiler and user to look around and are
not Pythonic.

Am I missing any other solutions?

You can use a different assignement syntax for outer scope variables;
for instance in Scheme there is "set!" which can do that.
BTW, I do not think the ability to have read-write closures is that
useful in an OOP language; just use objects. I would ignore this
"issue". OTOH, I do agree that Python scope rules are not 100%
perfect,
but I would content myself with changing the rule for "for" loops (see
http://groups.google.it/groups?hl=it....lang.python.*)

Michele Simionato

[Donn Cave]

In article <5vJjc.13116$Qy.1954@fed1read04>,
"Mark Hahn" <ma**@prothon.org> wrote:
....

I guess the whole problem is my insistence on simple scope indentification
by looking at the variable. It causes the var to need to be tagged.
Well, in a sense this is a simplistic avoidance of scope. Scope
is how unqualified identifiers are resolved. You hope that actual
usage is simple enough that a relative qualifier will prop up the
weaknesses of Python's half-lexical, half-dynamic system; Greg
points out that it doesn't handle more complex usage like nested
functions (and Simon's list comprehension / loop). You can dismiss
those as uncommon problems, but then this whole feature addresses
a problem that bothers only those who choose to be afflicted.
I feel strongly that the Python mixture of declaration (global), default
(where assigned) and broken (closures) is broken overall and has to be fixed
in Prothon. I take this as a given. So I see these possible solutions:

1) My Ruby-like symbols, which I think are readable and fast-compilable.

2) Word-like symbols, which are large, less readable (too me) and
cluttering.

3) Declarations, which cause the compiler and user to look around and are
not Pythonic.

Am I missing any other solutions?

I've already talked about making scope purely lexical, only explicit
dynamic name space binding.
http://groups.google.com/groups?selm...sure&oe=UTF-8&
output=gplain

As I said there, declaration isn't an interesting part of that,
but the idea that declarations are "not Pythonic" strikes me as
particularly absurd (not to mention just seeing you, of all people,
offer this criticism.) What is "class"? What is "def"?

Donn Cave, do**@u.washington.edu

[Mark Hahn]

Donn Cave wrote:

In article <5vJjc.13116$Qy.1954@fed1read04>, Well, in a sense this (&var) is a simplistic avoidance of scope. Scope
is how unqualified identifiers are resolved.
Scope is a noun, not a verb. To me a scope is just a namespace defined by
syntax. There are many ways to specify what scope a var belongs in, and
qualification using &var is just as valid as any other.
Greg points out that it doesn't handle more complex usage like nested
functions (and Simon's list comprehension / loop). You can dismiss
those as uncommon problems, but then this whole feature addresses
a problem that bothers only those who choose to be afflicted.
It turns out that Greg and I were mistaken. The &var syntax can easily
handle unlimited nested scopes and not even slow up my one-pass compiler. I
explained this on the Prothon list.

I'll take a look at Simon's list comprehension problem next. There might be
a solution for that also.
As I said there, declaration isn't an interesting part of that,
but the idea that declarations are "not Pythonic" strikes me as
particularly absurd (not to mention just seeing you, of all people,
offer this criticism.)
I didn't mean to be critical, just stating pros and cons.
What is "class"?
Be fair. You know that I didn't throw out classes on a capricious whim.
What is "def"?

I go through crazy moments where I consider every possibility and throw out
ideas. I considered the idea of replacing def with func (def is misnamed
after all) and that proposal lasted about 30 minutes. Another idea that
lasted about 45 minutes was changing __init__ to init. Please don't hold
anything against me during these trial-idea times. Wait until you see the
final Prothon before you criticize my wanton destruction of the Python
heritage. It also wouldn't hurt to hear you voice on the Prothon mailing
list influencing the outcome.

[Donn Cave]

In article <52Ujc.16275$Qy.3111@fed1read04>,
"Mark Hahn" <ma**@prothon.org> wrote:

Donn Cave wrote:

In article <5vJjc.13116$Qy.1954@fed1read04>,

Well, in a sense this (&var) is a simplistic avoidance of scope. Scope
is how unqualified identifiers are resolved.

Scope is a noun, not a verb. To me a scope is just a namespace defined by
syntax. There are many ways to specify what scope a var belongs in, and
qualification using &var is just as valid as any other.

Whatever you want scope to mean, that's up to you, but let's
observe that whatever you want to call it, programming languages
have in common a need to resolve multiple occurrences of an
identifier without syntactical aids, and some of them manage
to do it just fine in a fairly complex code structure.

As I said there, declaration isn't an interesting part of that,
but the idea that declarations are "not Pythonic" strikes me as
particularly absurd (not to mention just seeing you, of all people,
offer this criticism.)

I didn't mean to be critical, just stating pros and cons.

What is "class"?

Be fair. You know that I didn't throw out classes on a capricious whim.

I actually had forgotten that you threw out class, that's not
my point. Declarations are "Pythonic", because Python code is
necessarily full of declarations. When you reject a solution
because it's "not Pythonic", that is structurally a criticism.
I don't care how you rationalize your preferences in these
matters, really, and it might be that you would do better to
leave that part alone and just state your preferences. There's
nothing more inflammatory in a place like this than an absurd
proposition.
I go through crazy moments where I consider every possibility and throw out
ideas. I considered the idea of replacing def with func (def is misnamed
after all) and that proposal lasted about 30 minutes. Another idea that
lasted about 45 minutes was changing __init__ to init. Please don't hold
anything against me during these trial-idea times. Wait until you see the
final Prothon before you criticize my wanton destruction of the Python
heritage. It also wouldn't hurt to hear you voice on the Prothon mailing
list influencing the outcome.

You can't afford to indulge my tastes in programming languages,
because the result would be utterly foreign to Python users.
I use Python because it works. Roughly the 2.0 subset of the
language is all I know and seem to need to know to make programs
work. When I dream of a better language, it's not pasting new
gimmicks on Python, it's really a radically different direction.
OOP languages are today's FORTRAN.

Donn Cave, do**@u.washington.edu

[Bengt Richter]

On Wed, 28 Apr 2004 14:21:18 -0700, Donn Cave <do**@u.washington.edu> wrote:
[...]

work. When I dream of a better language, it's not pasting new
gimmicks on Python, it's really a radically different direction.

You teaser ;-)

Regards,
Bengt Richter

[Mark Hahn]

Donn Cave wrote:

When I dream of a better language, it's not pasting new
gimmicks on Python, it's really a radically different direction.

I've daydreamed the same thing and I've thought a classless language was
radical. If it turns out to only be a gimmick in the end and not reap the
payoffs I've been daydreaming about then I'll be quite dissapointed.

If you focus on the closure &var then you are missing the exciting parts of
the language picture. I don't need to ask questions about the exciting
parts.

Can you share some of your daydream ideas?

[Greg Ewing]

Mark Hahn wrote:

It turns out that Greg and I were mistaken. The &var syntax can easily
handle unlimited nested scopes and not even slow up my one-pass compiler.

It does incur the expense of a run-time lookup for
intermediate-scoped variables, however.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Mark Hahn]

Greg Ewing wrote:

Mark Hahn wrote:

It turns out that Greg and I were mistaken. The &var syntax can
easily handle unlimited nested scopes and not even slow up my
one-pass compiler.

It does incur the expense of a run-time lookup for
intermediate-scoped variables, however.

Prototype-based systems incur a prototype chain lookup expense on every
single attribute lookup. This is a disadvantage compared to class-based
systems. See the Lieberman paper linked near the top of the Prothon home
page.

That same paper also discusses a cache method that effectively eliminates
that expense. That same expense and cache fix will apply without change to
the closure lookup.

So the bottom line is there will effectively be no expense. We won't be
working on performance in Prothon until July or August though, so you'll
have to take my word on that until then.

[Donn Cave]

In article <cfYjc.17360$Qy.5220@fed1read04>,
"Mark Hahn" <ma**@prothon.org> wrote:
....

Can you share some of your daydream ideas?

Not really my ideas, it's pretty much all there in Haskell
and Clean (though I have no experience with the latter.)
Pure functional, strong static typing with type inference,
compile to native. It isn't clear that it's ideal - there
may be some inherent limitations to exception handling, the
execution model is often awkward (cf. Monad) at least for
the beginner programmer. So there's probably room for yet
another variation on the theme, but I'd be using Haskell
now if I could (weakness of platform support, institutional
acceptance.)

Haskell is good for you, though, even if you can't put it
to use in practice. It's a thoroughly different approach
that's at least good for perspective. And it's white space
structured.

Donn Cave, do**@u.washington.edu

[A. Lloyd Flanagan]

Greg Ewing <gr**@cosc.canterbury.ac.nz> wrote in message news:<c6************@ID-169208.news.uni-berlin.de>...

Mark Hahn wrote:

You cannot. Yes it literally means the immediately surrounding function.
In your example, I can't think of any scheme we've discussed that accesses x
in function f. Python surely cannot.

Python can't write to it, but at least it can read it.
Prothon apparently can't even read it.

Actually, when I tried the code I got a NameError. I don't see why I
would want to access a variable defined in an inner scope from an
outer scope; this seems like a great way to clutter up the namespace
and confuse the issue of what the variable actually refers to.

[Mark Hahn]

A. Lloyd Flanagan wrote:

Actually, when I tried the code I got a NameError. I don't see why I
would want to access a variable defined in an inner scope from an
outer scope; this seems like a great way to clutter up the namespace
and confuse the issue of what the variable actually refers to.

I assume you are talking about running that code in Python after removing
the & from &x?

That was supposed to be Prothon code that somehow defined x in function f
from the statement &x = 42, even though that statement was in the inner
function h. The equivalent python code would have the statement x = 42
inside the function f. Greg was asking if I was claiming that Prothon could
do this "magic" somehow from function h (which Prothon cannot).

We were always talking about an x local to f being referred to in h.