Why we will use obj$func() often

[A. Lloyd Flanagan]

I guess I'll go back to the Prothon mailing lists with my tail between my
legs....

Don't do that. It appears that this list is currently hosting even
more really grumpy people than usual.
Don't pay them any attention, maybe they'll go away.

 

[David MacQuigg]

It is _possible_. But it is not a very good idea.


Other than the basic premise of Prothon, every single decision I've seen
you make (or consider) looks wholly stylistic, awkward or even arcane,
and the opposite of the one I, or I think Guido, would have chosen.
Being a fan of Io, I think prototype-languages are interesting. Even so
far, I lost interest in looking at the actual main feature of Prothon,
after seeing all the extra baggage that was brought on in unecessary
stylistic changes.

Seriously considering every single possible proposal is not
constructive. Without a strong sense of what the language should look
like, Prothon is going to continue to look more and more like Perl.
It's already most of the way there.

Mark: """
Please hold off your ad hominem attacks until the product is
designed, thank you very much. """

I would take this as constructive criticism, not an ad-hominem attack.

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

Adding syntax or making changes just because it allows you to do
something that can't be done in Python is not good. We have to look at
*use cases* for these features and compare them to a well-written
Python equivalent. Then, we can see if the benefit is worth the extra
syntax. We spend far to much time debating syntax without a clear
benefit in mind. Show us a nice closure.

-- Special syntax to indicate binding of functions. Python solves
this problem neatly, at the expense of some implicitness.
bound_func = cat1.func # cat1 is an instance
unbound_func = Cat.func # Cat is a class
Prothon's insistence on having not a trace of class-like behavior has
opened a can-of-worms. Iron out the wrinkles on one place and they
pop up in another.

== Benefits of Prothon ==

In spite of these criticisms I do believe Prothon has made a big
contribution in the *simplification* of classes. There are also some
smaller items worth looking at ( break tags, uniform syntax for
mutation!, boolean?, ... )

-- Dave

 

[Mark Hahn]

There's a rule in experiments that you should only change one thing at a
time, trying to answer a single question with each change. Prothon started
out asking two questions:

Well, we didn't really start out to ask questions. We started out to design
a new language. We happened to like Python so we stole most of the syntax
from Python. Tim Peters and some other Pythoneers saw the existence of
Prothon as an opportunity to get some of these questions answered though for
Python.

* Does implementing an interpreter on top of the Apache Portable Runtime
for the sake of free threading work? (Presumably the answer is yes, since
Prothon does run. I haven't seen performance numbers on Prothon, though.)
* Is prototyping a workable replacement for a class-based object system?
Unclear, since I don't know that anyone has written sizable systems
in Prothon yet.

The problem is that if you then make a whole bunch of additional

changes --

a 'with' statement,

This was required. Not having a class statement meant there was no way to
group the definition of functions and other attribute assignments together
when building a prototype or even a plain object. When playing with early
versions of the language it was unusable without the "with".

changing the rules for indenting

Actually no rules changed for indenting. Well, we added a rule that you
couldn't mix tabs and spaces within a single block, but that is not an
unreasonable requirement. We also added a new way to do continuations, but
that is optional.

changing the names of various built-in methods

The names are totally unchanged. We just changed the style to camelCase and
added ! and ? for readability. These are all mechanical changes and no
memorization is required.

it becomes harder for Python users to try out
the new language for a while because there are more changes they have to
cope with. After a certain point the number of crossover users dwindles to
near-zero.

Yes, many people are afraid to try new things. That is a shame. Of course
if it was identical to Python many people still wouldn't try it.

I think everyone here is operating under fear, uncertainty, and doubt. Most
of the reports on the Prothon mailing list of people who have actually
picked up Prothon and played with it have been happy. People look at the
surface and are prejudiced, just like looking at people with different skin
color.

The best example is the current suggestion that self be changed to the
dollar-sign. Now anyone with any intelligence knows that changing the 4
letters "self" to the one symbol $ does nothing to change the language, but
several people here on c. l. p. claim that because you see dollar-signs
Prothon has now "become Perl". That is narrow-minded prejudice. What's
funny is that many people were happy with the current Prothon's use of
period for self but object to dollar-sign because now it looks like Perl.
Go figure.

None of these changes is critical or results in a 100%
improvement in functionality (or even a 10% one), but their collective
effect is to make the distance too great to cross conveniently; you might as
well start a new language with a blank sheet of paper at that point.

Don't forget that we are not claiming to be Python. We intended from the
beginning to be a new language. We are using everything from Python that
isn't broken, and we get to define what is broken in Python

We are definitely fighting a battle to improve things while keeping the best
of Python. There is no way to make everyone happy. There have been people
who have come to our mailing list whose "suggestions" for Prothon were to
basicly keep Prothon exactly like Python and not change anything. There are
also people who claim that any change from the Self language means that it
is not a real Prototype-based language. And of course a smattering of
people who claim it must be like Lisp

 

[Mark Hahn]

$ is basically a character as far as glyphs go, it's a
full-height glyph with ascenders and descenders, is very similar to a
capital S, and generally makes reading code much harder as it obscures
word-shape; .this or even self.this is much easier to read because you
can pick out the words using your learned vocabulary of word-shapes.

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?

 

[Mark Hahn]

I would take this as constructive criticism, not an ad-hominem attack.

Yes, I admitted I was mistaken. I was upset when I read the message and I
misread it as a slur.

Adding syntax or making changes just because it allows you to do
something that can't be done in Python is not good. We have to look at
*use cases* for these features and compare them to a well-written
Python equivalent. Then, we can see if the benefit is worth the extra
syntax. We spend far to much time debating syntax without a clear
benefit in mind. Show us a nice closure.

The benefits of closures are well known. I'll give you the canonical
example, but I'm sure textbooks can give you many more (by the way, Python
cannot do this):

# tested example
def getFunc():
counter = 0
def count():
&counter += 1
print &counter
return count

c = getFunc()
c() # prints 1
c() # prints 2
c() # prints 3

 

[Mark Hahn]

Mike, you haven't been keeping up with the other thread. I think the
decision is now:

fish_height$some_where()

That is like SO two-hours-ago. Marcia like, told me that Biff like, said
that Trish like, said camelCase was SO out, can you BELIEVE IT????

 

[Jack Diederich]

I think everyone here is operating under fear, uncertainty, and doubt. Most
of the reports on the Prothon mailing list of people who have actually
picked up Prothon and played with it have been happy. People look at the
surface and are prejudiced, just like looking at people with different skin
color.

Oh please, don't conflate irrational prejudice (racism) with rational
prejudice (it looks perl-ish, and I don't like the way perl looks, therefore
I don't like the way Prothon looks). Your accusation isn't up to the level
of that fellow spewing Totalitarian rhetoric about the "mental sickness" of
people who wrote/use python, but it isn't far off.

-jack

 

[Mike C. Fletcher]

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?

Depends on the font . Certainly $ is going to have the most
(negative) impact on readability, but the other three are all basically
lightweight enough that they don't read as characters (basically any
glyph that fills the same space as a lower-case o is going to markedly
change the shape of a word. ` is the least likely to be read as a
character, but is really hard to distinguish from ', so likely not a
great choice. ^ doesn't occupy the middle space, so doesn't get read as
a character either. ~ doesn't read as one either because it doesn't
touch the baseline.

$, however, is going to be familiar to your PERL aficionados, and
familiarity counts a lot for those who are familiar with it, regardless
of whether it's technically easier to read. The other three are
basically just arbitrary punctuation, so people don't have any
associations built up with them (they don't look at them and
automatically think "attribute access"). The dot character does have
lots of attribute-access associations; hence a leading dot (which
doesn't read as a character) will tend to test favourably on both scales
(practical and familiar).

Have fun,
Mike

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

 

[Fredrik Lundh]

(by the way, Python cannot do this)

sure can, if you use mutable integers.

# tested example
def getFunc():
counter = 0
def count():
&counter += 1
print &counter
return count

</F>

 

[Mark Hahn]

Oh please, don't conflate irrational prejudice (racism) with rational
prejudice (it looks perl-ish, and I don't like the way perl looks, therefore
I don't like the way Prothon looks). Your accusation isn't up to the level
of that fellow spewing Totalitarian rhetoric about the "mental sickness" of
people who wrote/use python, but it isn't far off.

I apologize to anyone that I offended by thinking that I related the
problems of racism to language discussion. I realize now that the analogy
was poorly chosen, even if based on something. I just meant that people
"pre-judge" Prothon based on it's looks.

 

[Mark Hahn]

That is like SO two-hours-ago. Marcia like, told me that Biff like, said
that Trish like, said camelCase was SO out, can you BELIEVE IT????

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

Boy, I better shut up. I'm just getting myself in deeper and deeper trouble
every message I post today.

 

[Mike C. Fletcher]

Mark Hahn wrote:
....

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

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

*poof*

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

 

[Mel Wilson]

Fascinating. Most users never even notice this stuff, let alone getting
so worked up about it that they start a whole separate language .
After all, they don't generally even know that metaclasses *exist* and
just know that it all works exactly as they would expect. You for
instance, were describing how the interpreter just knows that a class
can't be the target of an unbound class method. Sure, *maybe* it's all
a hideously complex mess that has people running screaming from Python
in horror, but from where I sit it is an extremely elegant system that
most people use without any impedance mismatch at all.

I perhaps encountered this..

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

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

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

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

Regards. Mel.

 

[David MacQuigg]

The benefits of closures are well known. I'll give you the canonical
example, but I'm sure textbooks can give you many more (by the way, Python
cannot do this):

Sorry for my ignorance, oh master. :>)

# tested example
def getFunc():
counter = 0
def count():
&counter += 1
print &counter
return count

c = getFunc()
c() # prints 1
c() # prints 2
c() # prints 3

Here is how I would do it in Python:

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

c = Accumulator()
c.bump()
c.bump()
c.bump()

It took me a few minutes to understand what the "closure" was doing.
The Python code is more clear ( at least for anyone who will have to
be working with classes anyway). There is nothing new to learn.

Functionality = same
Size of Source Code = same
Transparency = Python wins

-- Dave

P.S. A sincere apology for my gibe above. I couldn't resist. :>)

 

[Jack Diederich]

Sorry for my ignorance, oh master. :>)


Here is how I would do it in Python:

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

c = Accumulator()
c.bump()
c.bump()
c.bump()

A more word-for-word translation of the Prothon would be
def countup():
count = [0]
def f():
count[0] += 1
print count[0]
return f

c = countup()
c()
c()
c()

But yeah, using an object as an accumulator is more
transparent.

-jackdied

 

[Mel Wilson]

The benefits of closures are well known. I'll give you the canonical
example, but I'm sure textbooks can give you many more (by the way, Python
cannot do this):

# tested example
def getFunc():
counter = 0
def count():
&counter += 1
print &counter
return count

c = getFunc()
c() # prints 1
c() # prints 2
c() # prints 3

It can, if you spell '&' differently:

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

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


Regards. Mel.

 

[Donn Cave]

Depends on the font . Certainly $ is going to have the most
(negative) impact on readability, but the other three are all basically
lightweight enough that they don't read as characters (basically any
glyph that fills the same space as a lower-case o is going to markedly
change the shape of a word. ` is the least likely to be read as a
character, but is really hard to distinguish from ', so likely not a
great choice. ^ doesn't occupy the middle space, so doesn't get read as
a character either. ~ doesn't read as one either because it doesn't
touch the baseline.

$, however, is going to be familiar to your PERL aficionados, and
familiarity counts a lot for those who are familiar with it, regardless
of whether it's technically easier to read. The other three are
basically just arbitrary punctuation, so people don't have any
associations built up with them (they don't look at them and
automatically think "attribute access"). The dot character does have
lots of attribute-access associations; hence a leading dot (which
doesn't read as a character) will tend to test favourably on both scales
(practical and familiar).

Hm, I do have some associations with the other three, and
also with $ in an infix position. Maybe I have more junk
than usual in my mental closet, but we are supposed to
venerate the aged so I will report without embarrassment
that 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. VMS is still
around, too.

The C use of ~ (bitwise negation operator) and ^ (bitwise
xor) should be a problem, but otherwise I guess ~ seems
like a character to me too. In an infix position. hi~ho
vs. hi_ho, same look to me. They are also operators in
the Plan 9 rc shell, incidentally - glob match and distributive
concatenation, respectively.

Any of the four would be an unhappy choice, in my view.
Maybe there's some way to use :

Donn Cave, (e-mail address removed)

 

[Mark Hahn]

sure can, if you use mutable integers.

That's interesting. I've never heard of them. Can you show me a code
example?

 

[Erik Max Francis]

That's interesting. I've never heard of them. Can you show me a code
example?

Make a container. Put an integer in it. Pass the container around.
Change the integer that's contained in it.

 

[Mark Hahn]

Sorry for my ignorance, oh master. :>)

That's ok grasshopper

Here is how I would do it in Python:

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

It took me a few minutes to understand what the "closure" was doing.
The Python code is more clear ( at least for anyone who will have to
be working with classes anyway). There is nothing new to learn.

Functionality = same
Size of Source Code = same
Transparency = Python wins

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

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

P.S. A sincere apology for my gibe above. I couldn't resist. :>)

I'm sure I deserve it.