What is good about Prothon?

[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+functions 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,
      "Readability 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/