A 'Python like' language

[Peter Hickman]

Well after all this discussion it would appear that a 'Python like'
language has appeared => Prothon. http://www.prothon.org/index.html

Very alpha, sort of like Python (if you consider the indenting is what
makes Python unique) and sort of Ruby in its use of prefixes to define
scoping etc (although there is no reference to this trait being borrowed
from Ruby). It also quotes Self as being an influence.

[Mark Hahn]

> Not quite the same, as with Prothon it looks like it always relates to

the self object, whereas in a `with' clause you can make it relates to
any object you wish.
Just to confuse the issue, I'd like to point out that in Prothon, the
leading dot does always relate to the self object, but the 'with' clause
sets the self object to any object you want at any time. So both statements
above are true at once. The concept of changing the self object on the fly
is somewhat bizzare, much like changing the protoype on the fly, which you
can also do.

Mark Hahn (Prothon Author)

"Erik Max Francis" <ma*@alcyone.com> wrote in message
news:40***************@alcyone.com... Valentino Volonghi aka Dialtone wrote:

Anyway GvR just posted on the python-dev saying this:

==
No, I want to reserve the leading dot for attribute assignment to a
special object specified by a 'with' statement, e.g.

with self:
.foo = [1, 2, 3]
.bar(4, .foo)
==

So another feature of this prothon (and a major one) is going to be a
python one
too.

Not quite the same, as with Prothon it looks like it always relates to
the self object, whereas in a `with' clause you can make it relates to
any object you wish.

--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
\__/ Drifting from woman-who-tries misconstrued / Shifting to
woman-wise -- Lamya

[Mark Hahn]

> I like that, too, but why do they require *two* extra levels of indenting
to trigger it? Surely one would be enough?

This is a miscommunication. When I say one extra level I mean the normal
indentation like after an if:. Two extra is what I think you mean by one
extra. In any case it works like you expect.

* I definitely don't like the line-noise & and @ prefixes.

At least I would never have to use the @ (who in their
right mind actually *wants* dynamic scoping in this day
and age?-)
I'm open to suggestions. I used the Ruby prefix system for two reasons.
One is the instant readability instead of searching around the code looking
for global keywords or assignment statements. The second is to get the fast
one-pass compiler. But everything in Prothon is subject to change until
7/04.

As far as the dynamic scoping, I only put that in for completeness. I had
all the others so I said what the hell. You don't have to use it. I have
some kind of vague idea how it might be used in something like wxWindows but
I have to work on that idea. Go the Prothon list and voice your opinion.
* A bit of syntactic sugar for defining prototype objects
wouldn't go amiss.
I agree completely. We are working on this area.
By the way, did anyone figure out how you give an object
multiple prototypes?
It sucks right now:

Proto = Proto1()
Proto.add_proto(Proto2)
obj = Proto()

There is a discussion about this whole area on the Prothon list right now.
f = someobj.somemeth
f()
Yes this is legal.
f = someobj.somemeth
someotherobj.g = f
someotherobj.g()

What does the "self" object inside the call to somemeth
refer to then -- someobj, or someotherobj?
It refers to someotherobj.

You can get the answer to these questions quickly youself with a download
from prothon.org.

Mark Hahn (Prothon Author)

"Greg Ewing (using news.cis.dfn.de)" <ie*******@sneakemail.com> wrote in
message news:c4*************@ID-169208.news.uni-berlin.de... Stephen Horne wrote:

On a separate issue, the Prothon developers seem to have the mistaken
view that commas influence line continuation in Python. They don't -
but parentheses, square brackets and braces do. Though the Prothon
extra-indentation system (which is similar to Haskells offside rule, I
suppose) is an interesting idea.

I like that, too, but why do they require *two* extra levels of
indenting to trigger it? Surely one would be enough?

Some other impressions:

* I'm not sure I like the leading-dot notation. The code
examples look untidy to my eyes; there's too much punctuation
and not enough stuff being punctuated. Maybe I could get
used to it... or maybe not.

* I definitely don't like the line-noise & and @ prefixes.
At least I would never have to use the @ (who in their
right mind actually *wants* dynamic scoping in this day
and age?-)

* A bit of syntactic sugar for defining prototype objects
wouldn't go amiss. Having to say

Thing = Base()
with Thing:
...

every time I want to define a class (oops, sorry, prototype)
would drive me batty. I'd much rather write something like

object Thing(Base):
...

By the way, did anyone figure out how you give an object
multiple prototypes? I don't remember seeing an example of
that.

* It's not clear whether there is any such thing as a bound
method in Prothon, i.e. whether you can do

f = someobj.somemeth
f()

and have it do what a Pythoneer would expect. And if so,
what happens if you do

f = someobj.somemeth
someotherobj.g = f
someotherobj.g()

What does the "self" object inside the call to somemeth
refer to then -- someobj, or someotherobj?

Answering that question may shed some light on what was
asked earlier: Do we really need classes?

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

[Mark Hahn]

> Yes, this seemed interesting to me too. But when arrived at the sentence

"Prothon only allows tabs for indentation" I couldn't continue reading ;-)
It appears we will be bowing to pressure and switching to spaces.

Mark Hahn (Prothon Author)

"Michele Simionato" <mi***************@poste.it> wrote in message
news:95**************************@posting.google.c om... David MacQuigg <dm*@gain.com> wrote in message

news:<o5********************************@4ax.com>. ..

What I found most interesting about this language is that it *doesn't
use classes* !! All objects are derived directly from other objects,
some of which are "prototypes", that is, objects which were designed
to be just templates to produce other objects.

Yes, this seemed interesting to me too. But when arrived at the sentence
"Prothon only allows tabs for indentation" I couldn't continue reading ;-)

Michele Simionato

[Mark Hahn]

Speed tests on Prothon will be meaningless now. The code is chock full of
debug stuff and is not optimized, either by humans or compiler. We mean it
when we say pre-alpha.

"Jon Franz" <jf****@neurokode.com> wrote in message
news:ma************************************@python .org...

David MacQuigg <dm*@gain.com> wrote in message news:<o5********************************@4ax.com>. ..

What I found most interesting about this language is that it *doesn't
use classes* !! All objects are derived directly from other objects,
some of which are "prototypes", that is, objects which were designed
to be just templates to produce other objects.

Yes, this seemed interesting to me too. But when arrived at the sentence
"Prothon only allows tabs for indentation" I couldn't continue reading

;-)
I think the move to tabs-only for indentation was to allow for
single-pass compiling. I'm not saying it was a good move, just that
that's my guess for the reason :)

What I found interesting was:
- the use of the Apache Portable Runtime
(to provide threads, file and network services)
- native threads via locks on each object
- the stackless-ness
- multiple interpreters via native threads

It remains to be seen whether those sorts of changes result
in any significant speed differences. I may try writing some
multithreaded test scripts and running them this weekend to see if
an actual performance increase exists over multi-threaded python
- if so, the internals may be of interest to the python community
itself.
Has anyone else already performed that sort of performance
comparison?

~Jon Franz
NeuroKode Labs, LLC
513.260.5788

[Mark Hahn]

> What does stacklessness do for me as an application programmer?

The first thing is lack of recursion limits. Later you will find
continuations and other cool things.

Mark Hahn (Prothon Author)

"Roy Smith" <ro*@panix.com> wrote in message
news:ro***********************@reader1.panix.com.. .

"Jon Franz" <jf****@neurokode.com> wrote:

What I found interesting was:
- the stackless-ness

What does stacklessness do for me as an application programmer?

[Paul Rubin]

"Mark Hahn" <ma**@prothon.org> writes:

What does stacklessness do for me as an application programmer?

The first thing is lack of recursion limits. Later you will find
continuations and other cool things.

You gonna have a real compiler? You might also take the opportunity
to back off on some of Python's dynamicness.

Have you looked at PyPy?

[Mark Hahn]

> But I wonder what effect the lack of reference counting has

on cache-friendliness of the memory management system.

I don't see how the lack of something could hurt the cache. Do you mean the
garbage colector? The mark and sweep just behaves like another app running
at the same time and uses a hunk of the cache to do it's job. Other than
that I can't think of anything unfriendly to the cache. Am I missing
something in your question?

- the stackless-ness

I wonder what effect that has on the ability of C code to
make callbacks into the interpreter.

The interpreter supports C code calling Prothon code and vice versa. Also
either one can call a function without knowing what it is written in. If
you look at the codebase you will see examples of every possible
combination.

Mark Hahn (Prothon Author)
"Greg Ewing (using news.cis.dfn.de)" <ie*******@sneakemail.com> wrote in
message news:c4*************@ID-169208.news.uni-berlin.de... Jon Franz wrote:

What I found interesting was:
- native threads via locks on each object

Presumably this is bearable because of the lack of reference
counting, so that objects don't need to be locked and unlocked
at too frantic a rate.

But I wonder what effect the lack of reference counting has
on cache-friendliness of the memory management system.

- the stackless-ness

I wonder what effect that has on the ability of C code to
make callbacks into the interpreter.

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

[Mark Hahn]

> I do not yet know in detail how Prothon deals with module
namespaces. These are important for larger scale programs,
so I hope they got that right.

I hope so too. We basicly have "module globals" exactly like Python. See
"Module Globals and Real Globals" at http://prothon.org/description-3.htm.
Please let me know if we got it wrong.

One thing I'm missing on the website is support for basic
structured datatypes like the list and the dictionary in Python.
This is identical to Python. Dict is not fully implemented at this time.

Mark Hahn (Prothon Author)
"Ype Kingma" <yk*****@accessforall.nl> wrote in message
news:40*********************@news.xs4all.nl... Michele Simionato wrote:

David MacQuigg <dm*@gain.com> wrote in message
news:<o5********************************@4ax.com>. ..

What I found most interesting about this language is that it *doesn't
use classes* !! All objects are derived directly from other objects,
some of which are "prototypes", that is, objects which were designed
to be just templates to produce other objects.
Yes, this seemed interesting to me too. But when arrived at the sentence
"Prothon only allows tabs for indentation" I couldn't continue reading

;-)
The implementation of indentation is a minor issue.
Many editors have facilities to deal with them.
The point is that Prothon uses indentation. I hope
this will help in making it at least as easy to read
and maintain as Python. Who knows, at some point Prothon
might 'fall back' to spaces...

I like the prototypes _very_ much. They leave out many of the
implicit mechanisms in classes and they are relatively easy
to explain.

My first impression is that one can use prototypes like classes,
but they allow more flexibility. I wonder what influence they
will have on the classic class/object dichotomy in OO land.

As for the 'with' statement: I remember getting introduced to it
in Pascal, where it led to confusion an did not contribute to
code readability because of that. Pascal allowed more than
one variable to be used in the 'with' statement iirc.

On the contrary, the examples in Prothon are quite readable:
no confusion because there is only one implied variable, and
there is syntax (the leading dot) to show where it is used.

I do not yet know in detail how Prothon deals with module
namespaces. These are important for larger scale programs,
so I hope they got that right.

One thing I'm missing on the website is support for basic
structured datatypes like the list and the dictionary in Python.
The syntax support that Python has for these greatly
contributes to useability.

Regards,
Ype

[Sean Ross]

> > * A bit of syntactic sugar for defining prototype objects

wouldn't go amiss. Having to say

Thing = Base()
with Thing:
...

every time I want to define a class (oops, sorry, prototype)
would drive me batty. I'd much rather write something like

object Thing(Base):
...

In Io (www.iolanguage.com):

Thing := Object clone do(
# evaluates in context of Thing, i.e., Thing is the locals object of
do()
slot := "new slot for Thing"
)

Thing slot print # <- "new slot for Thing"

There's some fancy footwork going on that I won't go into at the moment -
its 5am - but suffice to say that namespaces are handled by objects and
message forwarding and one of the tricks of this process is that a method
has 'self', 'proto', 'sender', and 'locals' slots. In the case of do(),
locals == self == sender (I think). Anyway, for Prothon, perhaps you'll
want to reserve "do" for blocks, so we'll try "where":

Thing = Object.clone() where:
attr = "new attribute for Thing"
print Thing.attr # <- "new attribute for Thing"
I'm not sure how that'd be made to work though - in Io, do() is just another
method of Object (there are no keywords).

The namespaces are handled by objects idea seems to play out nicely - for
one thing, there's no reason to distinguish globals via capitalization.
Also, having two forms of assignment (one for creation(binding), and one for
update(re-binding)) eliminates alot of the need for the '.' prefix stuff in
Prothon - use "self.attr" once on creation to let the namespace know what
you're doing and from then on , as long as you don't shadow it by creating a
local of the same name, you can just say "attr". If you're only doing
updates on "attr", in a given namespace, you never need to use "self.attr" -
the lookup mechanism will just resolve it for you.
Anyway, that's enough from me, I have a lab exam to study for.

Sean

[Sean Ross]

"Mark Hahn" <ma**@prothon.org> wrote in message
news:37S9c.58035$cx5.39835@fed1read04...

By the way, did anyone figure out how you give an object
multiple prototypes?

It sucks right now:

Proto = Proto1()
Proto.add_proto(Proto2)
obj = Proto()

There is a discussion about this whole area on the Prothon list right now.

perhaps:

Proto = Proto1.clone().__bases__ = (Proto2, )
obj = Proto1.clone()

or

Proto = Proto1.clone().include(Proto2) # <- might want to save that for
mixins
obj = Proto1.clone()

or not

[Mark Hahn]

> or that you had come to this conclusion from a different route

That's actually impossible to tell. The period prefix used with the "with"
clause came first, which comes from Python 3.0. Then the capitalization was
independent I think. But I used to Program in Ruby so the whole concept of
being able to tell scope by just looking at the vars might be from Ruby.

In any case, if it came before, it must be credited.

"Peter Hickman" <pe***@semantico.com> wrote in message
news:40**********************@news.easynet.co.uk.. .

Mark Hahn wrote:

although there is no reference to this trait being borrowed from Ruby

I will fix that.

Cheers, actually I wasn't sure if it was inspired by Ruby or that you
had come to this conclusion from a different route. Looks interesting.

[Sean Ross]

"Sean Ross" <sr***@connectmail.carleton.ca> wrote in message
news:Bc*******************@news20.bellglobal.com.. .
[snip]

perhaps:

Proto = Proto1.clone().__bases__ = (Proto2, )
obj = Proto1.clone()

or

[snip]

I saw your post to prothon-user re:

P3 = proto( q, P1, P2)
It's a new prototype, inheriting from q, P1, and P2.

Nice.

[Joe Mason]

In article <BrS9c.58293$cx5.57010@fed1read04>, Mark Hahn wrote:

But I wonder what effect the lack of reference counting has
on cache-friendliness of the memory management system.

I don't see how the lack of something could hurt the cache. Do you mean the
garbage colector? The mark and sweep just behaves like another app running
at the same time and uses a hunk of the cache to do it's job. Other than
that I can't think of anything unfriendly to the cache. Am I missing
something in your question?

This, I think:

http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html

Joe

[Mark Hahn]

That was a great read. Thanks. I'll have to chew on it.

"Joe Mason" <jo*@notcharles.ca> wrote in message
news:sl****************@gate.notcharles.ca...

In article <BrS9c.58293$cx5.57010@fed1read04>, Mark Hahn wrote:

But I wonder what effect the lack of reference counting has
on cache-friendliness of the memory management system.

I don't see how the lack of something could hurt the cache. Do you mean the garbage colector? The mark and sweep just behaves like another app running at the same time and uses a hunk of the cache to do it's job. Other than that I can't think of anything unfriendly to the cache. Am I missing
something in your question?

This, I think:

http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html

Joe

[Dang Griffith]

On Sat, 27 Mar 2004 02:24:29 GMT, Steve Lamb <gr**@despair.dmiyu.org>
wrote:

On 2004-03-26, John Roth <ne********@jhrothjr.com> wrote:

"D Martin" <dg*****************@hotmail.com> wrote in message
news:ax%8c.9470$wg1.4018@edtnps84...

3 solutions: 1. Use spaces instead of tabs. Hit the space bar yourself, or an editor
that replaces tabs with spaces.
2. Include as a .py or text file instead of inline.
3. Get a different email program.

All of these fail for one simple reason. Let's hit
the chorus, guys:

"We're right, everybody else needs to change..."

Hey, that's the Chorus from the Microsoft song! You're the one using
Lookout! You're the one complaining about the shortfalls in your tools
because Microsoft sings that song. *YOU* deal with it.

It's not a Microsoft problem. I use a webmail interface (for
email, not newsgroups), and regardless of which browser I use,
tabs are eliminated. I'm not thinking it's a browser problem
either. My suspicion is that some part of the back-end is
removing tabs because some other part of the back-end system
uses tabs for delimiters. I know it's a non-Microsoft
back-end (I think it's FreeBSD). Who should *I* rant at? ;-)

When sending snippets, making a separate attachment can be
counterproductive since 1) it breaks the flow of any explanation,
and 2) many people are (justifiably) afraid to open attachments.
So attaching a file is not reader-friendly, though it does
solve the problem for the writer.

--dang

[François Pinard]

[Mark Hahn]

Yes, this seemed interesting to me too. But when arrived at the sentence
"Prothon only allows tabs for indentation" I couldn't continue reading ;-)

It appears we will be bowing to pressure and switching to spaces.

This might be good news. Despite a bit curious about prototype-based
languages, I initially stopped reading about Prothon when I saw that it
chose mandatory TABs. `make' is the only tool for which I still give in
such things :-).

Allow me a question. Is there some inter-operability sought between
Prothon and Python? That could ease taming communities. As far as I
understood, so far, these are currently meant as incompatible beasts.

--
François Pinard http://www.iro.umontreal.ca/~pinard

[Stephen Horne]

On 28 Mar 2004 21:49:07 -0500, aa**@pythoncraft.com (Aahz) wrote:

In article <1f********************************@4ax.com>,
Stephen Horne <st***@ninereeds.fsnet.co.uk> wrote:

I missed that. There's good precedent - it's the Pascal 'with' block,
but better (the leading dot tells you that you're dealing with a
'with' item rather than normal scoping rules). But - well - just
recently, people keep telling me that indented blocks are purely about
control flow. I keep disagreeing, but no-one has bothered agreeing
with me so I was feeling rather lonely and miserable in this crusade
:-(

Huh? Where were they telling you that? (I don't read all of c.l.py by
a long shot, 'specially when I've just gotten back from PyCon.) From my
POV, indented blocks are about program structure and namespaces. Saying
that ``class`` refers purely to control flow definitely misses the point.

My replies were...

Message-ID: <eu********************************@4ax.com>

Message-ID: <j6********************************@4ax.com>

I'm sure google can give you the full threads.
--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[Daniel Dittmar]

Joe Mason wrote:

In article <BrS9c.58293$cx5.57010@fed1read04>, Mark Hahn wrote:

But I wonder what effect the lack of reference counting has
on cache-friendliness of the memory management system.

I don't see how the lack of something could hurt the cache. Do you
mean the garbage colector? The mark and sweep just behaves like
another app running at the same time and uses a hunk of the cache to
do it's job. Other than that I can't think of anything unfriendly
to the cache. Am I missing something in your question?

This, I think:

http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html

On the other hand, reference counting requires access to the memory even if
only a reference is copied. This can't be good for cache locality either.

Daniel

[Glenn Andreas]

In article <BSR9c.57832$cx5.56065@fed1read04>,
"Mark Hahn" <ma**@prothon.org> wrote:

Not quite the same, as with Prothon it looks like it always relates to
the self object, whereas in a `with' clause you can make it relates to
any object you wish.

Just to confuse the issue, I'd like to point out that in Prothon, the
leading dot does always relate to the self object, but the 'with' clause
sets the self object to any object you want at any time. So both statements
above are true at once. The concept of changing the self object on the fly
is somewhat bizzare, much like changing the protoype on the fly, which you
can also do.

Out of curiousity (and on a somewhat related topic), how do you handle
"class variables" - i.e., variables that exist in the "super" object,
and should be accessable by all "sub objects"?

Accessing them is straightforward - for "foo.bar" if foo doesn't have
bar, but it inherits from an object that does have bar, you get that,
but what about foo.bar on the LHS of an expression? So does "foo.bar =
5" add a "bar" slot to "foo" or does it change bar in the parent object?

Self had a full blown system for variable access & setting, combined
with its multiple inheritance for some pretty interesting abilities
(essentially, all "getters" and "setters" were functions, so you could
have something be a constant by only providing a getter, etc...)

NewtonScript actually had two different assignment operators "=" and
":=" which determined how it behaved (though it got complex because it
sort of had multiple inheritance - everything inherited from _two_
parents, the "real" parent and a "_proto", which seems strange, but it
made sense in the runtime of the Newton, but that's a bit off topic).

[Paul Rubin]

"Mark Hahn" <ma**@prothon.org> writes:

That was a great read. Thanks. I'll have to chew on it.

Aside from those rather esoteric issues, pure mark/sweep gc has
traditionally worked best in smaller systems, since the "mark" phase
involves touching every live pointer in the whole system, which are
scattered through all of memory. As the system keeps running, memory
gets more and more fragmented and cache and paging performance get
worse and worse. Also, besides touching all the live objects in the
mark phase, you also have to touch all the garbage in the sweep phase.

With a stop-and-copy gc, you still have to touch all the data during
gc, but you don't have to touch the garbage. Also, after the gc is
done, you've copied all the live data to a contiguous region, so it's
not fragmented any more.

Fancier (generational) schemes use mixed copying and mark/sweep
strategies to gc recently created objects the most often, etc.

Just as with numerical linear algebra or sorting or alpha-beta search,
there are simple gc techniques that work ok, but getting really high
performance is a well-studied subject with a lot of literature and
lore about it. I believe Andrew Appel wrote a book or survey paper
on it in the early 90's that you might like to look at.

[Daniel Dittmar]

Paul Rubin wrote:

Just as with numerical linear algebra or sorting or alpha-beta search,
there are simple gc techniques that work ok, but getting really high
performance is a well-studied subject with a lot of literature and
lore about it. I believe Andrew Appel wrote a book or survey paper
on it in the early 90's that you might like to look at.

The book 'Garbage Collection'
http://www.amazon.com/exec/obidos/tg...glance&s=books
has a chapter on 'Cache-Conscious Garbage Collection'.

Daniel

[Mark Hahn]

> Is there some inter-operability sought between Prothon and Python?

No, I assumed from day one that the lack of classes meant a fundamental
incompatability. However, even though I am designing a new language, I have
no desire to re-invent anything for any arbitrary reason, so I chose to
"steal" everything from Python unless it conflicted with the prototype
paradigm or I or other Pythoners considered the current Python broken. I am
changing to all of Guido's "regrets" for example.

One example of something I consider broken in Python is the generator scheme
using the def keyword and not allowing nesting of generators. I just added
docs for my gen keyword today to the Prothon website.

----- Original Message -----
From: "François Pinard" <pi****@iro.umontreal.ca>
To: "Mark Hahn" <ma**@prothon.org>
Cc: <py*********@python.org>
Sent: Monday, March 29, 2004 4:29 AM
Subject: Re: A 'Python like' language
[Mark Hahn]

Yes, this seemed interesting to me too. But when arrived at the sentence
"Prothon only allows tabs for indentation" I couldn't continue reading

;-)
It appears we will be bowing to pressure and switching to spaces.

This might be good news. Despite a bit curious about prototype-based
languages, I initially stopped reading about Prothon when I saw that it
chose mandatory TABs. `make' is the only tool for which I still give in
such things :-).

Allow me a question. Is there some inter-operability sought between
Prothon and Python? That could ease taming communities. As far as I
understood, so far, these are currently meant as incompatible beasts.

--
François Pinard http://www.iro.umontreal.ca/~pinard

[Mark Hahn]

> So does "foo.bar = 5" add a "bar" slot to "foo" or does it change bar in
the parent object?

It took me great trouble to learn to use attribute instead of slot to keep
Prothon in sync with Python. I even had to globally replace "slot" with
"attr" in all my code a week ago, so I'll be replacing your use of slot with
attribute.

"foo.bar = 5" will always add an attribute bar to foo. You have to say
"parent.bar = 5", or if foo is the current self object, you would say "^bar
= 5". The caret(^) prefix reads as "super" and replaces the period prefix
when you want atrribute lookup to start at the parent of self instead of at
self. This was documented yesterday on the website.

I realize that there is not currently any automatic way to change a value
found by inheritance. I'm open to suggestions. None of the Prothon
features will be cast in stone until 7/04 so make your suggestions known at
Prothon mailing lists.

"Glenn Andreas" <ga******@no.reply> wrote in message
news:ga****************************@news.mpls.visi .com...

In article <BSR9c.57832$cx5.56065@fed1read04>,
"Mark Hahn" <ma**@prothon.org> wrote:

Not quite the same, as with Prothon it looks like it always relates to
the self object, whereas in a `with' clause you can make it relates to
any object you wish.

Just to confuse the issue, I'd like to point out that in Prothon, the
leading dot does always relate to the self object, but the 'with' clause
sets the self object to any object you want at any time. So both statements above are true at once. The concept of changing the self object on the fly is somewhat bizzare, much like changing the protoype on the fly, which you can also do.

Out of curiousity (and on a somewhat related topic), how do you handle
"class variables" - i.e., variables that exist in the "super" object,
and should be accessable by all "sub objects"?

Accessing them is straightforward - for "foo.bar" if foo doesn't have
bar, but it inherits from an object that does have bar, you get that,
but what about foo.bar on the LHS of an expression? So does "foo.bar =
5" add a "bar" slot to "foo" or does it change bar in the parent object?

Self had a full blown system for variable access & setting, combined
with its multiple inheritance for some pretty interesting abilities
(essentially, all "getters" and "setters" were functions, so you could
have something be a constant by only providing a getter, etc...)

NewtonScript actually had two different assignment operators "=" and
":=" which determined how it behaved (though it got complex because it
sort of had multiple inheritance - everything inherited from _two_
parents, the "real" parent and a "_proto", which seems strange, but it
made sense in the runtime of the Newton, but that's a bit off topic).

[Greg Ewing (using news.cis.dfn.de)]

Mark Hahn wrote:

But I wonder what effect the lack of reference counting has
on cache-friendliness of the memory management system.
I don't see how the lack of something could hurt the cache. Do you mean the
garbage colector?

A running Python program creates and discards certain kinds
of objects (e.g. integers, tuples, stack frames) at a very
high rate. Due to reference counting, the fact that these
objects have been discarded is discovered very quickly, and
their memory released. Subsequent allocations are likely to
re-use the same memory, which is likely to be in cache.

A pure mark-and-sweep system, on the other hand, tends to
keep on allocating fresh memory and letting the garbage
objects pile up until there is no more fresh memory, only
then pausing to reclaim the garbage. This is a very bad
access pattern for cache purposes.

Back when the addition of a mark-and-sweep collector to
Python was being debated, this argument was put forward as
a reason why replacing reference counting with mark-and-sweep
wouldn't obviously be an improvement, and could make things
worse.

Python currently has both reference counting *and* mark
and sweep, which sounds redundant, but the combination seems
to work very well.
The interpreter supports C code calling Prothon code and vice versa.

I don't doubt that it's possible, I was just wondering how
easy it is. Stackless-type systems tend to make this rather
more convoluted than just making a C function call. I'll take
a look at the code some time and find out.

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

[Greg Ewing (using news.cis.dfn.de)]

Sean Ross wrote:

Proto = Proto1.clone().__bases__ = (Proto2, )
obj = Proto1.clone()

or

Proto = Proto1.clone().include(Proto2) # <- might want to save that for
mixins
obj = Proto1.clone()

With the syntactic sugar I suggested this would be

object Proto(Proto1, Proto2):
...

and I wouldn't really care what went on under the covers.

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

[Zipher]

[Mark Hann]

Obviously Prothon is not Python compatible, so I have taken the liberty of
implementing many changes that have been imagined for the almost mythical
Python 3.0...

Gee, my love of Python makes me feel a little guilty about looking at
another language, but Prothon does look appealing. Classes really do
start looking archaic... Would a threesome be out of the question?

My Python3k suggestions for Prothon:

--Take advantage of iterators early on for return values to avoid
things like having both dict.items() and dict.iteritems().
(Decorators add even larger possibilities for fresh syntax and other
considerations.)

--Choose "{:}" syntax for empty dict creation to reserve "{}" for
sets. (Or: use "{}" for both, and do automatic "set-to-dict
promotion" upon encountering a (key, value) assignment.)

--Functions that return multiple, but unique, values should return a
set, not a list, to communicate same (ex: dict.keys(), dir(), etc.).
(Consider iterator caveat above, however.)

Such functions often have surprising uses for set operations anyway.
Consider, for example, using set operations on dir() to answer
questions like Which parent functions/variables get re-assigned in the
child class? or What new fns/vars does this child add?

--Dict should inherit from Set.

--No Dict.update(), since this is now identical with Set.__ior__()
(i.e. d1 |= d2).

Could follow Python's behavior with regard to key collisions (a matter
of contentious debate if I remember), OR perhaps even better:

--Dict object could contain optional "collision function attribute"
that is called to resolve values on key collisions.

Consider, for example, an easy Bag(Dict) object with said attribute
assigned to "operator.add" for the union method(s). This would also
maintain the >10x speed factor (in Python anyway) of using underlying
C-implmentation rather that hand iteration through dicts.

--With prothon's "immutability" bit and other considerations, does the
language need both tuples AND lists?

Also, perhaps this is an opportunity to address handling single vs.
multiple element parameters. That is, how to avoid things like both
list.extend() and list.append() -- which one adds only a single
element? If the language had a way to indicate whether a parameter
should be treated as an atom vs. a collection, it would reduce a lot
of ambiguous (within an object) and inconsistent (across objects)
method names and the unending debate that seems to occur each time.

Perhaps Python's later enhancements (decorators?) could make this more
natural, or maybe a new construct would be required...

BTW, I vote in favor of character case being semantically meaningful.
I like the language informing me (and enforcing) semantic meaning
through syntax (much like Python's indention). Ditto for bang-endings
(ex. list.sorted!).

Off the cuff, but only two cents....

Zipher

[Greg Ewing (using news.cis.dfn.de)]

Mark Hahn wrote:

f = someobj.somemeth
someotherobj.g = f
someotherobj.g()

What does the "self" object inside the call to somemeth
refer to then -- someobj, or someotherobj?

It refers to someotherobj.

You have a problem, then. This means passing functions around
is fragile. If you store one in an attribute of an object, it
mutates into something different when you get it back out
again.

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

[Mark Hahn]

I need a better understanding of this. You are suggesting the self stay
with a function like a closure of sorts?

In my mind, anytime you say obj.func(), func is called on obj, no ifs ands
or buts. How could it be otherwise? When would you want it otherwise?

You say fragile. What breaks?
"Greg Ewing (using news.cis.dfn.de)" <ie*******@sneakemail.com> wrote in
message news:c4*************@ID-169208.news.uni-berlin.de...

Mark Hahn wrote:

f = someobj.somemeth
someotherobj.g = f
someotherobj.g()

What does the "self" object inside the call to somemeth
refer to then -- someobj, or someotherobj?

It refers to someotherobj.

You have a problem, then. This means passing functions around
is fragile. If you store one in an attribute of an object, it
mutates into something different when you get it back out
again.

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

[Mark Hahn]

> Stackless-type systems tend to make this rather more convoluted than just
making a C function call.

I define a function call as:

call_func(ist, self, func_sym, parm_cnt, lbl_val_arr, dyn_locals);

This call is the same for interpreted Prothon or internal C code. It has
the self object, the symbol telling the function name, and the passed
parameters. ist is a struct passed around everywhere to keep interpreter
state and keep things re-entrant. dyn_locals is used for dynamic local
compatilility in C (which has never been used and may be pulled).
lbl_val_arr is a C array (length of parm_cnt) of object pairs of labels (sym
objects) and value objects. The labels allow one to do func(x=value).
Usually, internally the labels are NULL. This structure supports
func(*list, **dict) even internally.

You may call this convoluted if you wish.
"Greg Ewing (using news.cis.dfn.de)" <ie*******@sneakemail.com> wrote in
message news:c4*************@ID-169208.news.uni-berlin.de...

Mark Hahn wrote:

But I wonder what effect the lack of reference counting has
on cache-friendliness of the memory management system.

I don't see how the lack of something could hurt the cache. Do you mean the garbage colector?

A running Python program creates and discards certain kinds
of objects (e.g. integers, tuples, stack frames) at a very
high rate. Due to reference counting, the fact that these
objects have been discarded is discovered very quickly, and
their memory released. Subsequent allocations are likely to
re-use the same memory, which is likely to be in cache.

A pure mark-and-sweep system, on the other hand, tends to
keep on allocating fresh memory and letting the garbage
objects pile up until there is no more fresh memory, only
then pausing to reclaim the garbage. This is a very bad
access pattern for cache purposes.

Back when the addition of a mark-and-sweep collector to
Python was being debated, this argument was put forward as
a reason why replacing reference counting with mark-and-sweep
wouldn't obviously be an improvement, and could make things
worse.

Python currently has both reference counting *and* mark
and sweep, which sounds redundant, but the combination seems
to work very well.

The interpreter supports C code calling Prothon code and vice versa.

I don't doubt that it's possible, I was just wondering how
easy it is. Stackless-type systems tend to make this rather
more convoluted than just making a C function call. I'll take
a look at the code some time and find out.

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

[Mark Hahn]

> --Take advantage of iterators early on for return values to avoid

things like having both dict.items() and dict.iteritems().
Interestiong idea. Generators are fully supported so I could do this now.
So gens would have to be allowed absolutely everywhere lists are allowed (is
trhis possible?). Or are you thinking the user should type
List(dict.items()) ?
--Choose "{:}" syntax for empty dict creation to reserve "{}" for
sets. (Or: use "{}" for both, and do automatic "set-to-dict
Also cool. Maybe <> for sets? Prothon doesn't support <> as != so it is
free.
--Functions that return multiple, but unique, values should return a
set, not a list, to communicate same (ex: dict.keys(), dir(), etc.).
Also cool.
--Dict should inherit from Set.
Also cool (I feel like the credits of Holy Grail saying Also wik).
--No Dict.update(), since this is now identical with Set.__ior__()
(i.e. d1 |= d2).

Cool.

.... snipped ...

All cool.
--With prothon's "immutability" bit and other considerations, does the
language need both tuples AND lists?
I like this a lot. Tuples are already implemented internally as lists.

.... more good stuff snipped ...
Off the cuff, but only two cents....
More like a few dollars. This is really good stuff. Can I talk you into
hanging out on the Prothon list now and then, at least until we get the core
language sorted out?
"Zipher" <av*****@moonman.com> wrote in message
news:30**************************@posting.google.c om... [Mark Hann]

Obviously Prothon is not Python compatible, so I have taken the liberty of implementing many changes that have been imagined for the almost mythical Python 3.0...

Gee, my love of Python makes me feel a little guilty about looking at
another language, but Prothon does look appealing. Classes really do
start looking archaic... Would a threesome be out of the question?

My Python3k suggestions for Prothon:

--Take advantage of iterators early on for return values to avoid
things like having both dict.items() and dict.iteritems().
(Decorators add even larger possibilities for fresh syntax and other
considerations.)

--Choose "{:}" syntax for empty dict creation to reserve "{}" for
sets. (Or: use "{}" for both, and do automatic "set-to-dict
promotion" upon encountering a (key, value) assignment.)

--Functions that return multiple, but unique, values should return a
set, not a list, to communicate same (ex: dict.keys(), dir(), etc.).
(Consider iterator caveat above, however.)

Such functions often have surprising uses for set operations anyway.
Consider, for example, using set operations on dir() to answer
questions like Which parent functions/variables get re-assigned in the
child class? or What new fns/vars does this child add?

--Dict should inherit from Set.

--No Dict.update(), since this is now identical with Set.__ior__()
(i.e. d1 |= d2).

Could follow Python's behavior with regard to key collisions (a matter
of contentious debate if I remember), OR perhaps even better:

--Dict object could contain optional "collision function attribute"
that is called to resolve values on key collisions.

Consider, for example, an easy Bag(Dict) object with said attribute
assigned to "operator.add" for the union method(s). This would also
maintain the >10x speed factor (in Python anyway) of using underlying
C-implmentation rather that hand iteration through dicts.

--With prothon's "immutability" bit and other considerations, does the
language need both tuples AND lists?

Also, perhaps this is an opportunity to address handling single vs.
multiple element parameters. That is, how to avoid things like both
list.extend() and list.append() -- which one adds only a single
element? If the language had a way to indicate whether a parameter
should be treated as an atom vs. a collection, it would reduce a lot
of ambiguous (within an object) and inconsistent (across objects)
method names and the unending debate that seems to occur each time.

Perhaps Python's later enhancements (decorators?) could make this more
natural, or maybe a new construct would be required...

BTW, I vote in favor of character case being semantically meaningful.
I like the language informing me (and enforcing) semantic meaning
through syntax (much like Python's indention). Ditto for bang-endings
(ex. list.sorted!).

Off the cuff, but only two cents....

Zipher

[Mark Hahn]

If you were designing a new interpreter, would you consider reference
counting an evil pain for C coders (as I did) and use some other GC, or do
you think I made a mistake? Is there a compromise?
"Greg Ewing (using news.cis.dfn.de)" <ie*******@sneakemail.com> wrote in
message news:c4*************@ID-169208.news.uni-berlin.de...

Mark Hahn wrote:

But I wonder what effect the lack of reference counting has
on cache-friendliness of the memory management system.

I don't see how the lack of something could hurt the cache. Do you mean the garbage colector?

A running Python program creates and discards certain kinds
of objects (e.g. integers, tuples, stack frames) at a very
high rate. Due to reference counting, the fact that these
objects have been discarded is discovered very quickly, and
their memory released. Subsequent allocations are likely to
re-use the same memory, which is likely to be in cache.

A pure mark-and-sweep system, on the other hand, tends to
keep on allocating fresh memory and letting the garbage
objects pile up until there is no more fresh memory, only
then pausing to reclaim the garbage. This is a very bad
access pattern for cache purposes.

Back when the addition of a mark-and-sweep collector to
Python was being debated, this argument was put forward as
a reason why replacing reference counting with mark-and-sweep
wouldn't obviously be an improvement, and could make things
worse.

Python currently has both reference counting *and* mark
and sweep, which sounds redundant, but the combination seems
to work very well.

The interpreter supports C code calling Prothon code and vice versa.

I don't doubt that it's possible, I was just wondering how
easy it is. Stackless-type systems tend to make this rather
more convoluted than just making a C function call. I'll take
a look at the code some time and find out.

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

[Paul Rubin]

"Mark Hahn" <ma**@prothon.org> writes:

I need a better understanding of this. You are suggesting the self stay
with a function like a closure of sorts?

In my mind, anytime you say obj.func(), func is called on obj, no ifs ands
or buts. How could it be otherwise? When would you want it otherwise?

Well, that's not how Python does it, though doing it some other way may
not necessarily be "fragile".

[Paul Rubin]

"Mark Hahn" <ma**@prothon.org> writes:

If you were designing a new interpreter, would you consider
reference counting an evil pain for C coders (as I did) and use some
other GC, or do you think I made a mistake? Is there a compromise?

I think as long as you're using an interpreter, any performance that you
get back from improved cache behavior by reference counting will be lost
in the noise. If you're serious about performance you really should be
thinking about a native-code compiler. Only after that should you worry
much about the fine points of gc design.

[Jon Franz]

"Mark Hahn" <ma**@prothon.org> wrote in message news:<6gS9c.58150$cx5.19190@fed1read04>...

Speed tests on Prothon will be meaningless now. The code is chock full of
debug stuff and is not optimized, either by humans or compiler. We mean it
when we say pre-alpha.

Not necessarily - I'm not looking for raw performance, but rather
scalability. Many of the changes you've made in Prothon could either
improve or hurt scalability and CPU utilization in multithreaded
scenarios. Of course, as a pre-alpha, no full conclusions can be
drawn. But for example, what if Prothon scaled as well (or just
within an order of magnitude) as standard Python? Considering the
non-optimized nature of Prothon, that would bode very well, and could
start discussions in the Python community as to whether your sort of
APR based system with GC and multiple interpreters with native threads
is something to look at. After all, I do believe that the last time
removing the global interpreter lock was seriously pondered and tests
were done, the APR was not considered (possibly due to it not existing
in a usable state at the time), nor was moving to such a stackless
backend on the table at the same time.

Anyway, I'm busy with client work, and looking for more clients, so
I don't have the time to write any tests write now; perhaps by the
time I do (or someone else does) Prothon will be more mature.

~Jon Franz
NeuroKode Labs, LLC

[Andrew Bennetts]

On Mon, Mar 29, 2004 at 10:46:42PM -0800, Mark Hahn wrote:

I need a better understanding of this. You are suggesting the self stay
with a function like a closure of sorts?

In my mind, anytime you say obj.func(), func is called on obj, no ifs ands
or buts. How could it be otherwise? When would you want it otherwise?
How is it possible to store a function from some object in another object
for later use, e.g. as a callback?

i.e. in Python syntax:

class C:
def __init__(self, callbackFunc):
self.callbackFunc = callbackFunc

def fireCallback(self):
self.callbackFunc()

c = C(someobj.method)

...

c.fireCallback()
You say fragile. What breaks?

The fragility I see is that storing a function in a variable doesn't modify
the function, but storing it as an attribute of an object does, i.e.

f = someobj.method
x = f
x()

behaves differently to:

otherobj.f = someobj.method
x = otherobj.f
x()

Python solves this by wrapping functions found in classes as (un)bound
methods (which keep track of the instance they were accessed from) -- but
functions found on *instances* (i.e. they are in the dict of the instance,
but not the class) are left alone. It works well :)

-Andrew.

[Gerrit]

Mark Hahn wrote:

--Take advantage of iterators early on for return values to avoid
things like having both dict.items() and dict.iteritems().

Interestiong idea. Generators are fully supported so I could do this now.
So gens would have to be allowed absolutely everywhere lists are allowed (is
trhis possible?). Or are you thinking the user should type
List(dict.items()) ?

If it would be a list, yes, or maybe even dict.items().aslist() or
similar. This because it is quite random for keys to be a list: it could
be a set. This has the advantage that one can do as in Ruby:
myobj.methods() - parent.methods(). But I'm not sure whether parent.methods()
is applicable to a prototype-based language.

--Functions that return multiple, but unique, values should return a
set, not a list, to communicate same (ex: dict.keys(), dir(), etc.).

Also cool.

It also applies to dict.items(). This could be either a generator or a
Set.

--Dict should inherit from Set.

Also cool (I feel like the credits of Holy Grail saying Also wik).

I have read (in c.l.py) that in Smalltalk, a Dict is a Set of Associates
or something similar. I don't know Smalltalk, but I like this idea of a
Set.

Gerrit.

--
Weather in Twenthe, Netherlands 30/03 13:25 UTC:
15.0°C wind 5.4 m/s E (57 m above NAP)
--
here will soon be Gerrit Holl's very own signature

[Gerrit]

Mark Hahn wrote:

But everything in Prothon is subject to change until > 7/04.

Is that April the 7th or July the 4th?

Gerrit.

--
Weather in Twenthe, Netherlands 30/03 13:25 UTC:
15.0°C wind 5.4 m/s E (57 m above NAP)
--
here will soon be Gerrit Holl's very own signature

[Glenn Andreas]

In article <5J1ac.64492$cx5.5801@fed1read04>,
"Mark Hahn" <ma**@prothon.org> wrote:

So does "foo.bar = 5" add a "bar" slot to "foo" or does it change bar in

the parent object?

It took me great trouble to learn to use attribute instead of slot to keep
Prothon in sync with Python. I even had to globally replace "slot" with
"attr" in all my code a week ago, so I'll be replacing your use of slot with
attribute.

"foo.bar = 5" will always add an attribute bar to foo. You have to say
"parent.bar = 5", or if foo is the current self object, you would say "^bar
= 5". The caret(^) prefix reads as "super" and replaces the period prefix
when you want atrribute lookup to start at the parent of self instead of at
self. This was documented yesterday on the website.

I realize that there is not currently any automatic way to change a value
found by inheritance. I'm open to suggestions. None of the Prothon
features will be cast in stone until 7/04 so make your suggestions known at
Prothon mailing lists.

Self gets around this problem by the way it handles assignments as
method calls, so assigning to a specific attribute/slot/ivar of a
parent/superclass/prototype is handled like explicitly calling the
method via a resend or directed resend.

What makes this work is the fact that inheritance is handled by
"flagging" the slot of the object as something that it inherits from, by
having an "*" after the name, which results in inerhitance coming from
explicitly named "paths" rather than some implicit (and usually hidden)
"__super__" (for example). So "parent* = anotherObject", "super* =
anotherObject" and "proto* = anotherObject" all define "anotherObject"
as something this object inerhits from. As a result, it is easy to
explicitly say "parent.foo", "super.foo", "proto.foo" to narrow down
which thing to inherit from.

Perhaps a similar thing can work for Prothon? (i.e, explicit "named"
inheritance instead of implicit anonymous inheritence via "^")?

You could even use "^" for the default "super" (the non-directed
resend), and then something like "^(anotherParent)" for the moral
equivalent of a directed resend.

Having named attributes/slots/ivars for inheritence also makes it easier
to handle dynamically changing multiple inheritence prototypes on the
fly (since you explicitly have a name for them)

[Terry Reedy]

What is 'this'? Who is 'you'? Where is the original suggestion? What did
who say what is fragile?

"Mark Hahn" <ma**@prothon.org> wrote in message
news:1J8ac.68390$cx5.23284@fed1read04...

I need a better understanding of this. You are suggesting the self stay
with a function like a closure of sorts?

In my mind, anytime you say obj.func(), func is called on obj, no ifs ands or buts. How could it be otherwise? When would you want it otherwise?

You say fragile. What breaks?

Trying to read cryptic top-posted comments that require me to spend minutes
trying to find the most like referent in order to make any sense is too
much work for me. I won't do it. Good bye.

Terry J. Reedy

[Ype Kingma]

Mark,

you wrote:

I do not yet know in detail how Prothon deals with module

namespaces. These are important for larger scale programs,
so I hope they got that right.

I hope so too. We basicly have "module globals" exactly like Python. See
"Module Globals and Real Globals" at http://prothon.org/description-3.htm.
Please let me know if we got it wrong.

I'm not a language lawyer, so that took a quite while to sink in.
Nevertheless, it looks right.

Good luck,
Ype

[Magnus Lyck?]

"Greg Ewing (using news.cis.dfn.de)" <ie*******@sneakemail.com> wrote in message news:<c4*************@ID-169208.news.uni-berlin.de>...

* A bit of syntactic sugar for defining prototype objects
wouldn't go amiss. Having to say

Thing = Base()
with Thing:
...

every time I want to define a class (oops, sorry, prototype)
would drive me batty.

What about just combining it to this?

with Thing = Base():
...

[Mark Hahn]

It is not clear to me why the complexity of named prototype paths are needed
right now, but that is not too surprising considering my inexperience with
proto-based languages like self. I will keep the options open as we learn.

It would be especially helpful if "self-aware" programmers tried some small
apps in Prothon in order to give some usage examples. (hint-hint)

"Glenn Andreas" <ga******@no.reply> wrote in message
news:ga****************************@news.mpls.visi .com...

In article <5J1ac.64492$cx5.5801@fed1read04>,
"Mark Hahn" <ma**@prothon.org> wrote:

So does "foo.bar = 5" add a "bar" slot to "foo" or does it change bar

in the parent object?

It took me great trouble to learn to use attribute instead of slot to keep Prothon in sync with Python. I even had to globally replace "slot" with
"attr" in all my code a week ago, so I'll be replacing your use of slot with attribute.

"foo.bar = 5" will always add an attribute bar to foo. You have to say
"parent.bar = 5", or if foo is the current self object, you would say "^bar = 5". The caret(^) prefix reads as "super" and replaces the period prefix when you want atrribute lookup to start at the parent of self instead of at self. This was documented yesterday on the website.

I realize that there is not currently any automatic way to change a value found by inheritance. I'm open to suggestions. None of the Prothon
features will be cast in stone until 7/04 so make your suggestions known at Prothon mailing lists.

Self gets around this problem by the way it handles assignments as
method calls, so assigning to a specific attribute/slot/ivar of a
parent/superclass/prototype is handled like explicitly calling the
method via a resend or directed resend.

What makes this work is the fact that inheritance is handled by
"flagging" the slot of the object as something that it inherits from, by
having an "*" after the name, which results in inerhitance coming from
explicitly named "paths" rather than some implicit (and usually hidden)
"__super__" (for example). So "parent* = anotherObject", "super* =
anotherObject" and "proto* = anotherObject" all define "anotherObject"
as something this object inerhits from. As a result, it is easy to
explicitly say "parent.foo", "super.foo", "proto.foo" to narrow down
which thing to inherit from.

Perhaps a similar thing can work for Prothon? (i.e, explicit "named"
inheritance instead of implicit anonymous inheritence via "^")?

You could even use "^" for the default "super" (the non-directed
resend), and then something like "^(anotherParent)" for the moral
equivalent of a directed resend.

Having named attributes/slots/ivars for inheritence also makes it easier
to handle dynamically changing multiple inheritence prototypes on the
fly (since you explicitly have a name for them)

[Mark Hahn]

> The fragility I see is that storing a function in a variable doesn't
modify

the function, but storing it as an attribute of an object does...
Aha, I see our problem now. In prothon, all variables are attributes of an
object. There is no distinction between variables and attributes. That is
part of the great simplification of Prothon.
they are in the dict of the instance, but not the class
See, another meaningless statement in classless Prothon.
How is it possible to store a function from some object in another
object for later use, e.g. as a callback?
Prothon is object-centric, not object-oriented or function-oriented. You
would pass a call-back object, not a function:

# module A
call_back_obj = Object()
def call_back_obj.fire():
#code with closure to do whatever ...
request_from_B(call_back_obj)

# module B
call_back_obj.fire()
"Andrew Bennetts" <an***************@puzzling.org> wrote in message
news:ma**************************************@pyth on.org... On Mon, Mar 29, 2004 at 10:46:42PM -0800, Mark Hahn wrote:

I need a better understanding of this. You are suggesting the self stay
with a function like a closure of sorts?

In my mind, anytime you say obj.func(), func is called on obj, no ifs ands or buts. How could it be otherwise? When would you want it otherwise?
How is it possible to store a function from some object in another object
for later use, e.g. as a callback?

i.e. in Python syntax:

class C:
def __init__(self, callbackFunc):
self.callbackFunc = callbackFunc

def fireCallback(self):
self.callbackFunc()

c = C(someobj.method)

...

c.fireCallback()

You say fragile. What breaks?

The fragility I see is that storing a function in a variable doesn't

modify the function, but storing it as an attribute of an object does, i.e.

f = someobj.method
x = f
x()

behaves differently to:

otherobj.f = someobj.method
x = otherobj.f
x()

Python solves this by wrapping functions found in classes as (un)bound
methods (which keep track of the instance they were accessed from) -- but
functions found on *instances* (i.e. they are in the dict of the instance,
but not the class) are left alone. It works well :)

-Andrew.

[Mark Hahn]

Goodbye.

"Terry Reedy" <tj*****@udel.edu> wrote in message
news:ma**************************************@pyth on.org...

What is 'this'? Who is 'you'? Where is the original suggestion? What did who say what is fragile?

"Mark Hahn" <ma**@prothon.org> wrote in message
news:1J8ac.68390$cx5.23284@fed1read04...

I need a better understanding of this. You are suggesting the self stay
with a function like a closure of sorts?

In my mind, anytime you say obj.func(), func is called on obj, no ifs ands

or buts. How could it be otherwise? When would you want it otherwise?

You say fragile. What breaks?

Trying to read cryptic top-posted comments that require me to spend

minutes trying to find the most like referent in order to make any sense is too
much work for me. I won't do it. Good bye.

Terry J. Reedy

[Mark Hahn]

> Is that April the 7th or July the 4th?

Sorry for the cultural bigotry. Make that July.

"Gerrit" <ge****@nl.linux.org> wrote in message
news:ma**************************************@pyth on.org...
Mark Hahn wrote:

But everything in Prothon is subject to change until > 7/04.

Is that April the 7th or July the 4th?

Gerrit.

--
Weather in Twenthe, Netherlands 30/03 13:25 UTC:
15.0°C wind 5.4 m/s E (57 m above NAP)
--
here will soon be Gerrit Holl's very own signature

[Mark Hahn]

"Magnus Lyck?" <ma****@thinkware.se> wrote in message
news:25**************************@posting.google.c om...

"Greg Ewing (using news.cis.dfn.de)" <ie*******@sneakemail.com> wrote in

message news:<c4*************@ID-169208.news.uni-berlin.de>...

* A bit of syntactic sugar for defining prototype objects
wouldn't go amiss. Having to say

Thing = Base()
with Thing:
...

every time I want to define a class (oops, sorry, prototype)
would drive me batty.

What about just combining it to this?

with Thing = Base():
...

[Mark Hahn]

(Sorry about the blank reply)

What about just combining it to this?

with Thing = Base():
Yes, I want to. But first I have to decide to get rid of Guido's aversion
to assignments returning a value.

Any ideas on how to implement assignment expressions and not have if x = y:
ambiguity problems?

I've considered using a different syntax for the expression version of "=",
such as ":=" or even left.replace!(right).

"Magnus Lyck?" <ma****@thinkware.se> wrote in message
news:25**************************@posting.google.c om... "Greg Ewing (using news.cis.dfn.de)" <ie*******@sneakemail.com> wrote in

message news:<c4*************@ID-169208.news.uni-berlin.de>...

* A bit of syntactic sugar for defining prototype objects
wouldn't go amiss. Having to say

Thing = Base()
with Thing:
...

every time I want to define a class (oops, sorry, prototype)
would drive me batty.

What about just combining it to this?

with Thing = Base():
...

[Paul Rubin]

"Mark Hahn" <ma**@prothon.org> writes:

Any ideas on how to implement assignment expressions and not have if x = y:
ambiguity problems?

I've considered using a different syntax for the expression version of "=",
such as ":=" or even left.replace!(right).

:= is the variant discussed most often around here. left.replace!(right)
only works if left is already bound to an object.

[Stephen Horne]

On Tue, 30 Mar 2004 14:58:44 +0200, Gerrit <ge****@nl.linux.org>
wrote:

Mark Hahn wrote:

But everything in Prothon is subject to change until > 7/04.

Is that April the 7th or July the 4th?

You didn't spot the little clue? As in _why_ the 4th of July?

:-)
--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[JanC]

Dang Griffith <no*****@noemail4u.com> schreef:

It's not a Microsoft problem. I use a webmail interface (for
email, not newsgroups), and regardless of which browser I use,
tabs are eliminated.
Read the HTML specs and you'll know why that happens.
I'm not thinking it's a browser problem either.

No, your browsers follow the specs...

A solution would be to write a backend function that replaces whitespace
(tabs, spaces) with the intended number of "space positions" encoded as
&nbsp;

--
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9