What is good about Prothon?

[David MacQuigg]

I'm concerned that with all the focus on obj$func binding, &closures,
and other not-so-pretty details of Prothon, that we are missing what
is really good - the simplification of classes. There are a number of
aspects to this simplification, but for me the unification of methods
and functions is the biggest benefit.

All methods look like functions (which students already understand).
Prototypes (classes) look like modules. This will make teaching OOP
much simpler, especially for the students and professional engineers
(non-CIS) that I am most concerned about. I teach electronic design
tools, not programming. Current plans are to include some basic
Python, no OOP. If I could add OOP with another 4 hours, I would do
it.

I've written a proposal for a prototype syntax that I believe captures
the essense of what is good in Prothon, while not departing too
radically from Python. see PrototypeSyntax .htm at
http://ece.arizona.edu/~edatools/Prothon/ I would like to get
feedback from Python experts on the potential problems with this
syntax. The major question is automatic translation of existing Python
programs to the new syntax. I'm one of those users who would not give
up the existing libraries in Python, no matter how good some
alternative language may be.

I would also like to get feedback from users on what they like or
dislike about this proposal. I will summarize this feedback in the
"Pros and Cons" section of the proposal.

Below are some excerpts from the syntax proposal. Please see the link
above for better formatting.

-- Dave

Proposed Prototype Syntax
=============== ==========
< snip >

Example of Simplified Classes ( Prototypes )
=============== =============== ==============

Animal --> Mammal --> Feline --> Cat
------- ------- ------- -------
numAnimals numMammals numFelines numCats
home genus
__init__() __init__() __init__() __init__()
.sound .sound
.name
show() show() show() show()
talk() talk()
proto Animal(object): # Inherit from the primitive object.
numAnimals = 0
home = "Earth"
....
<see the "OOP Chapter" at http://ece.arizona.edu/~edatools/Prothon/
for the complete example.>
....
proto Cat(Feline):
numCats = 0
__init__ :( n = "unknown", s = "Meow" ):
Feline.__init__ ()
Cat.numCats += 1
.name = n # Set instance variables.
.sound = s
show :(): # Define a "static method".
Feline.show()
print " Cats:", Cat.numCats
talk :():
print "My name is ...", .name
print "I am a %s from %s" % (.genus, .home)
Mammal.talk() # Call an unbound function.
print __self__ ### Diagnostic check.

cat1 = Cat() # Create instance.
with cat1: # Modify instance variables.
home = "Tucson"
genus = "feline"
name = "Garfield"

cat1.talk() My name is ... Garfield
I am a feline from Tucson
Mammal sound: Meow
<__main__.Cat object at 0x00A894B0>

Changes from Current Python
=============== ============
-- Keyword class is changed to proto.
-- All methods have the same form, identical to a simple function.
-- Function header lines are re-arranged. def --> : Parentheses are
optional.
-- self is replaced with a leading dot, and eliminated from the arg
list.
-- Current instance is available if ever needed via __self__
-- Instances can have their attributes modified in a with block.

Benefits of Proposed Syntax
=============== ============
-- Unification of all function forms ( bound, unbound, static, class,
lambda ). All will have the same form as a normal function
definition. This will make it easier to teach OOP. Students will
already understand functions and modules. OOP is a small step up. A
prototype will look just like a module ( except for the instance
variables ). See Parallels between Prototypes and Modules below.

-- Using an explicit __self__ variable avoids the magic first
argument, and makes it easier to explain instance variables. See the
sections below comparing a brief explanation of instance variables in
Python vs the simplified form. A full presentation of OOP, like pages
295-390 in Learning Python, 2nd ed. will likely be 1/2 the number of
pages. Not only is the basic presentation simpler, but we can
eliminate a lot of discussion of lambda functions, static methods,
etc.

-- All attributes of a prototype ( both data and functions ) will be
in a neat column, making it easier to find a particular attribute when
visually scanning a program. Understanding the structure of a program
will be almost as quick as seeing a UML diagram.

-- Lambda keyword will be gone. An anonymous function using normal
function syntax can be extremely compact. ( :x,y:x+y )

-- Method definitions will be less cluttered and less typing with
__self__ as a hidden variable.

-- Changing numerous attributes of an instance will be more
convenient. ( need use case )

-- Migration of Python programs to Prothon will be automatic and
reliable. ???

Pros and Cons of the Proposed Syntax
=============== =============== ======
Classlessness

Con: The proposed syntax is not purely classless. This is important
because ... ???

Unification of Methods and Functions

Pro1: Less to learn.

Con1: Experts don't care. Beginners don't need advanced method
syntax.

Pro2: Replace lambdas with standard function syntax.

Con2: ???

Explicit __self__

Pro1: Allows the unification of methods and functions.

Con1: ???

Pro2: Explanation of instance variables is simpler.

Con2: Using __self__ instead of a special first argument is less
explicit.

Pro3: Less typing and less clutter in method definitions.

Con3: Can use "s" or "_" instead of "self" to minimize typing and
clutter.

"Assignment " Syntax for Function Definitions

Pro1: See all the variables at a glance in one column.

Con1: ???

Pro2: Emphasize the similarity between data and functions as
attributes of an object.

Con2: ???

Symbol instead of def Keyword

Pro: Allows lambda functions to be included in the unification.

Con: Symbols are never as clear as keywords.

With Block

Pro: Saves typing the object name on each line.

Con: Making it too easy to modify prototypes after they have been
created will lead to more undisciplined programming.

Issues relevant to teaching OOP
=============== =============== =
Parallels between Prototypes and Modules
----------------------------------------
Ninety percent of what students need to know about prototypes is
already understood from their study of functions and modules. Even
some tricky issues are best explained by comparing to a parallel
situation with modules.
< snip >

Explanation of Instance Variables in Python
-------------------------------------------
""" Some of the variables inside the functions in a class have a
self. prefix. This is to distinguish local variables in the function
from "instance variables". These instance variables will be found
when the function is called, by searching the instance which called
the function. The way this works is that calling the function from an
instance causes that instance to be passed as the first argument to
the function call. So if you call cat1.talk(), that is equivalent to
Cat.talk(cat1) If you call cat1.set_vars( "Garfield", "Meow"), that is
equivalent to Cat.set_vars(ca t1, "Garfield", "Meow")

The "current instance" argument is auto-magically inserted as the
first argument, ahead of any other arguments that you may provide in
calling a method that is "bound" to an instance. Note: The
distinction between instances and classes is important here. If you
call a function from a class, that function is not bound to any
instance, and you have to supply the instance explicitly in the first
argument ( Cat.talk(cat1) )

The variable name self is just a convention. As long as you put the
same name in the first argument as in the body of the definition, it
can be self or s or even _ The single underscore is handy if you
want to maximally suppress clutter. """

Explanation of Simplified Instance Variables
--------------------------------------------
""" Some of the variables inside the functions in a prototype have a
leading dot. This is to distinguish local variables in the function
from "instance variables". When a function is called from an instance
( cat1.talk() ) a special global variable __self__ is automatically
assigned to that instance ( __self__ = cat1 ) Then when the function
needs an instance variable ( .sound ) it uses __self__ just as if you
had typed it in front of the dot ( __self__.sound ) The leading dot
is just an abbreviation to avoid typing __self__ everywhere. """

========== END ==============

[Mark Hahn]

"David MacQuigg" <dm*@gain.com > wrote ...

I'm concerned that with all the focus on obj$func binding

I would like to point out, as a technical detail, you will quickly find out
when you implement "your" Prothon, as I did in "my" Prothon, and Lenard
Lindstrom did in his Python implementation of "his" Prothon, that you MUST
focus on function/method binding on objects. This is where the
classlessness of Prothon versus classfulness of Python exhibits its
differences.

Ignoring the problem of calling the ancestor's version of a method by just
using the same old obj.func() will not work. You don't have to use the
current suggestion of obj$func() (we Prothonites may not use it either), but
you cannot live in denial about the need for it.

[Mike C. Fletcher]

David MacQuigg wrote:
....

All methods look like functions (which students already understand).

I think it might be more proper to say that you've made all functions
methods with an implicitly defined target, but I suppose the statement
is still technically true.
Benefits of Proposed Syntax
============== =============
-- Unification of all function forms ( bound, unbound, static, class,
lambda ). All will have the same form as a normal function
definition. This will make it easier to teach OOP. Students will
already understand functions and modules. OOP is a small step up. A
prototype will look just like a module ( except for the instance
variables ). See Parallels between Prototypes and Modules below.

This is nice. Not "I'm going to rush out to adopt a language because of
it" nice, but nice enough. I'm curious about one thing:

proto x( object ):
flog :( x, y ):
.x = x
a = x()
b = x()
a.flog = b.flog
a.flog()
print b.x

In other words, how do I hold a reference to a bound method/function if
there are no such things and only the "last access" determines what the
implicit target is? Just to be clear, I'm assuming you're going to have
storage *somewhere* so that:

a = module.do
a()

works.
-- Using an explicit __self__ variable avoids the magic first
argument, and makes it easier to explain instance variables. See the
sections below comparing a brief explanation of instance variables in
Python vs the simplified form. A full presentation of OOP, like pages
295-390 in Learning Python, 2nd ed. will likely be 1/2 the number of
pages. Not only is the basic presentation simpler, but we can
eliminate a lot of discussion of lambda functions, static methods,
etc.

This is a wash IMO, with the explicit "self" having a slight edge on
"Explicit is better than Implicit" grounds. You now have to explain
where the magic __self__ comes from instead of how self is bound when
you access the instance's method. They're both magic, the Python stuff
is just explicitly visible. Still, since you're coding it deep into
this new language, it'll be first nature to the Whateverthon programmer.

On a personal note, the moment where I "got" the concept of methods
(Python was my first OO language) was seeing "self" in the argument list
of a function and realising that it's just a parameter curried into the
function by doing x.method lookup. That is, it just looked like any
other function, the parameter was just a parameter, nothing special,
nothing requiring any extra knowledge save how it got bound (and that's
pretty darn simple). Coming from a structures+func tions background it
made complete sense.
-- All attributes of a prototype ( both data and functions ) will be
in a neat column, making it easier to find a particular attribute when
visually scanning a program. Understanding the structure of a program
will be almost as quick as seeing a UML diagram.

Can't say I find it particularly compelling as an argument, not if
introducing punctuation-itis is the cost, anyway. Most people I know
use syntax colouring editors, after all.
-- Lambda keyword will be gone. An anonymous function using normal
function syntax can be extremely compact. ( :x,y:x+y )

That particular example almost screams "don't do this", doesn't it?
:(x,y): x+y I can see as an improvement, but yawn, really. Making
function definitions expressions rather than statements would have the
same effect. By the way, how do you know when your lambda is finished?
I gather the ()s are required if using as an expression?
-- Method definitions will be less cluttered and less typing with
__self__ as a hidden variable.

I personally prefer explicit to implicit, but I know there's lots of
people who are big into saving a few keystrokes.
-- Changing numerous attributes of an instance will be more
convenient. ( need use case )

That's nice, but honestly, if you're doing a lot of this in cases
trivial enough to warrant the addition you should likely be refactoring
with a domain-modelling system anyway. Still, if you modify the with to
work something like this:

with x:
.this = 32
.that = 43
temp = 'this'*repeat
.something = temp[:55]

i.e. to just alter the implicit target of the block, not force all
variables to be assigned to the object, it seems a nice enough feature.
Pro2: Replace lambdas with standard function syntax.

Con2: ???

Fine, but no need to redefine the spelling for that save to make the
definition itself an expression that returns the function as a value and
allows one to drop the name. i.e. a = def ( y,z ): y+z would work just
as well if you could assign the result to a variable and figured out how
you wanted to handle the indentation-continuation thing to know when the
function ended.
Explicit __self__

Pro1: Allows the unification of methods and functions.

Con1: ???

Is hidden (implicit) magic that requires the user to learn rules as to
what the target is when treating functions/methods as first-class
objects. Not a big deal, really.
Pro2: Explanation of instance variables is simpler.

Con2: Using __self__ instead of a special first argument is less
explicit.

Um, can't say I see this as a huge pedagogical win. A function either
takes an argument self and can set attributes of the object, or a
function has access to a magical "global" __self__ on which it can set
attributes. I'll agree that it's nice having the same concept for
module and class variables, but seeing that as a huge win assumes, I
think, that those being taught are coming from a "globals and functions"
background rather than a structures and functions background. One type
is accustomed to altering their execution environment, the other to
altering solely those things which are passed into the function as
parameters.
Pro3: Less typing and less clutter in method definitions.

Con3: Can use "s" or "_" instead of "self" to minimize typing and
clutter.

That's a counter, not a con. Similarly "Explicit is better than
Implicit" is only a counter, not a con. A con would be: "presence of
variable of implicit origin" or "too much punctuation". Don't think
either is a huge concern.
"Assignment " Syntax for Function Definitions

Pro1: See all the variables at a glance in one column.

Con1: ???

Doesn't seem a particularly strong pro. IOW seems pretty minimal in
benefit. As for a con, the eye, particularly in a syntax-colouring
editor picks out keywords very well, while punctuation tends to blur
into other punctuation.
Pro2: Emphasize the similarity between data and functions as
attributes of an object.

Con2: ???

I see the pro, seems approx. the same to me.
With Block

Pro: Saves typing the object name on each line.

Con: Making it too easy to modify prototypes after they have been
created will lead to more undisciplined programming.

As specified, makes it only useful for trivial assignments. If you're
going to all the trouble of introducing .x notation to save keystrokes,
why not simply have with alter __self__ for the block so you can still
distinguish between temporary and instance variables?

In the final analysis, this really seems like about 3 separate proposals:

* I like the .x notation's universal applicability, it does seem
simple and elegant from a certain point of view
o I don't like the implicit __self__, but that's an integral
part of the proposal, so a wash
o I'd want clarification of how to store a reference to
another object's (bound) method (which is *extremely* common
in Python code for storing, e.g. callbacks)
* I really dislike the :( ): function definition notation,
"Readabilit y Counts". Why clutter the proposal with that?
* I'm neutral on the with: stuff, I'd much prefer a real block
mechanism similar to Ruby with (if we're using implicit targets),
the ability to specify the .x target for the block

So, the .x notation seems like it would be nice enough, but nothing else
really makes me jump up and down for it...

That said, I'd probably be willing to use a language that was running on
the PythonVM with a parser/compiler that supported the syntax. I'd be
totally uninterested in automated translation of Python code to the new
form. That's the kind of thing that can be handled by running on the
same VM just as easily as anything else and you then avoid lots of
migration headaches.

So, just as a marketing data-point; I'm not convinced that this is
markedly superior, but I'd be willing to try a language that differed
from Python in just the .x aspects to see whether it was worthwhile.

Have fun,
Mike

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

[Mark Hahn]

"Mike C. Fletcher" <mc******@roger s.com> wrote...

I'd want clarification of how to store a reference to
another object's (bound) method (which is *extremely* common
in Python code for storing, e.g. callbacks)
* I really dislike the :( ): function definition notation,
"Readabilit y Counts". Why clutter the proposal with that?
* I'm neutral on the with: stuff, I'd much prefer a real block
mechanism similar to Ruby with (if we're using implicit targets),
the ability to specify the .x target for the block

For what it's worth, you are basicly in agreement with the current proposals
for Prothon.

[Mike C. Fletcher]

Mark Hahn wrote:
....

For what it's worth, you are basicly in agreement with the current proposals
for Prothon.

Maybe I should add designing languages to my list of projects starved
for time :) .

Have fun,
Mike

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

[Mark Hahn]

"Mike C. Fletcher" <mc******@roger s.com> wrote ...

Maybe I should add designing languages to my list of projects starved
for time :) .

We'd love to have you...

[David MacQuigg]

On Mon, 26 Apr 2004 12:36:51 -0700, "Mark Hahn" <ma**@prothon.o rg>
wrote:
<snip>

Ignoring the problem of calling the ancestor's version of a method by just
using the same old obj.func() will not work. You don't have to use the
current suggestion of obj$func() (we Prothonites may not use it either), but
you cannot live in denial about the need for it.

I'll take this as a
Question: How does the iterpreter know that Mammal.talk is an unbound
function and not a new binding to Mammal?

Answer: For reference, I have marked the line in question with !!!

proto Cat(Feline):
numCats = 0
__init__ :( n = "unknown", s = "Meow" ):
Feline.__init__ ()
Cat.numCats += 1
.name = n # Set instance variables.
.sound = s
show :(): # Define a "static method".
Feline.show()
print " Cats:", Cat.numCats
talk :():
print "My name is ...", .name
print "I am a %s from %s" % (.genus, .home)
Mammal.talk() # Call an unbound function. <== <== !!!
print __self__ ### Diagnostic check.

I am assuming the same implicit rule that Python follows. Mammal is a
prototype (class). When you access a function from a class in Python,
you get an unbound function. When you access that same function from
an instance, you get a function bound to that instance.

cat1 = Cat("Garfield", "Meow")
cat2 = Cat("Fluffy","P urr") bf = cat1.talk # function Cat.talk bound to cat1
bf <bound function Cat.talk of <__main__.Cat object at 0x00A83D10>> bf() My name is ... Garfield
I am a feline from Earth
Mammal sound: Meow
<__main__.Cat object at 0x00A83D10>
uf = Mammal.talk # unbound function
uf <unbound function Mammal.talk>

In the rare situation where we need to explicitly change the current
instance: __self__ = cat2
uf() Mammal sound: Purr

Python's syntax does violate the "Explicit" rule, but it seems in this
case the "Practicali ty" rule over-rides. By making the function bound
or unbound, depending implicitly on the type of the object before the
dot, Python has avoided the need for an explicit binding syntax.

If we could come up with an explicit binding syntax that was not a
burden on either readability or clarity, then I would vote for a
change. To summarize the current proposals:

Prothon:
$var # var is attribute of self
^var # var is an attribute of a proto of self
obj.func() # func is an attribute of obj and bound to obj
obj$func() # func is an attribute of obj and bound to current self
x = obj.func # x is bound method of func attribute of obj and obj
x = obj$func # x is bound method of func attribute of obj and self
x = obj.attr(func) # x is unbound func

Python 3:
bf = cat1.talk # bound function
uf = Cat.talk # unbound function
bf() # call a bound function
uf() # call unbound function with current __self__

__self__ = cat2 # change __self__ ... rarely needed
uf() # call with cat2

The "Python 3" proposal follows current Python syntax except for the
use of a global __self__ variable instead of a special first argument.

-- Dave

[Mark Hahn]

"David MacQuigg" <dm*@gain.com > wrote ...

Mammal.talk() # Call an unbound function. <== <== !!!

This works great in Python, but in Prothon there is no such thing as a class
to tell the difference in the binding. The concept of a prototype is in the
programmer's mind, not the interpreter's, since every object can be a
prototype.

Feel free to make this an argument for Python 3, but quit comparing your
proposal to Prothon since it is not Prothon compatible.

You have argued this in the Prothon mailing lists for almost a month with
Greg and me. Please don't just start it up again here (about Prothon I
mean).

[Michael Geary]

> David MacQuigg wrote:

Mammal.talk() # Call an unbound function. <== <== !!!

Mark Hahn wrote: This works great in Python, but in Prothon there is no such thing
as a class to tell the difference in the binding. The concept of a
prototype is in the programmer's mind, not the interpreter's,
since every object can be a prototype.

I thought you'd already solved the problem anyway?

Given an object named 'obj' and a function attribute in that object named
'func':

obj.func # bound method
obj('func') # unbound function
obj$func # function bound to $ (self), e.g. for super calls

-Mike

[Mark Hahn]

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

I thought you'd already solved the problem anyway?

David has been insisting for weeks that we don't need the obj$func() form if
the interpreter just recognizes that obj is a prototype as Python does with
classes. This is a never-ending argument that I am trying to end,
especially since he has been using his argument to make claims about Prothon
being too complex.

I've got Has on one side of me who says that having prototype references
instead of copies makes it too much like Python and therefore it isn't
prototype-based and then David who thinks prototypes should be handled
internally like classes (which would actually make them classes) and an
occasional Lisper who thinks Prothon should be like Lisp. I knew I couldn't
please them all, but I thought I'd be able to please one or two :)