Loops and stuff (was Re: Python and Boehm-Demers GC, I have code.)

[Markus Kohler]

Michael Hudson <mwh21 at cam.ac.uk> writes:

> On 21 Jul 1999, Markus Kohler wrote:
> > "Tim Peters" <tim_one at email.msn.com> writes:
> > 
> > > [Tim]
> > > >     for i in xrange(10000000):
> > > >         pass
> > > > [and RC vs GC implications]
> > > 
> > > [Markus Kohler]
> > > > True.
> > > > IMHO this is one of Pythons major design flaws.
> > > 
> > > What, specifically?
> > 
> > That flaw is that loops are not implemented using closures. 
> 
> Sorry, how would that help?

It wouldn't help regarding performance, but increase the
expressiveness of the language. 

> 
> > Instead as far as I understand   loops in Python are implemented such that
> > the loop counter is created and destroyed for each step of the loop. 
> > 
> > You could compare this to tail recursive versus non-tail recursive functions. 
> > 
> > Also closures make the implementation of efficient loops more
> > difficult they have the advantage that loops and other control
> > structures can be better integrated into the OO concept. Smalltalk for
> > example doesn't need Iterators for that reason.
> 
> Python is not a functional programming language. 

It could be extended by some functional features.  
All I want is the integration of loops into the OO concept of the language. 

Loops are cannot be used as any other polymorph
function if you don't implement them with closures (please tell me
if there's another way). 

Smalltalk Example 

iterate over a container and do something for each element looks like this:

aContainer do:[:each | each doSomething]

because do: is just a method like any other method you can redefine it for each
class. 
This is very usefull because it allows to for example to loop over a Container
that contains two other Containers ("a" and "b" of an unknown type very easily:

do: aBlock
 a do: aBlock. 
 b do: aBlick. 


> As I understand it, you
> can't really have convenient closures because it is not lexically scoped
> (I can give you inconvenient closures...) and there were lengthy
> discussions about that some months back. I didn't follow it too closely
> because I didn't know what lexically scoped meant then, but the upshot was
> (I think) that lexical scoping isn't really the "Python way".
> 
> Python isn't really an OO language either, in the sense of something like
> Smalltalk or Eiffel.

IMHO it's very close to Smalltalk, also Guido probably wouldn't agree with me ...
And It has all essential OO features.  


The features that make it very similiar to Smalltalk are :
byte code interpreter, 
all data are objects (is that really true ?), 
crossplatform, 
reflection api, 
dynamically type checked, 

In fact I cannot remember any successfull language that is closer to 
Smalltalk than Python is. 


> 
> I have heard it said that Python is a language that "gets it's compromises
> exactly right" and that about sums it up for me.

I also like some things about Python. For example the module system, and how
easily external C functions can be integrated. 

> 
> > Lately ee have had already some examples in this group where loop
> > overhead was a major factor. 
> 
> Really? When? Sorry, I don't want to sound disbelieving, but I don't
> remember that.

It was about reading a file and put the words into some hash table. 
As far as I can remember to loop overhead was a dominating factor. 
And Python was much slower than perl for example. 

> 
> > I measured different kind of loops and
> > even the more general while loop was faster in squeak than anything
> > else in python.
> 
> Python, as I said, is neither functional nor purely OO; 

Ok it's not purely OO because you can define global functions. 
But it's anything else is pretty much OO. 

> it's not
> particularly fast either. Fast enough, generally.
> 
> > Functions calls seems also to be much slower in Python ...
> 
> *That* I believe. Not clear what to do about it though.

It's IMHO the overly complex function call mechanism, with it's 
default values on all that other stuff. I really can imagine it's difficult to 
make this fast. IMHO it's not worth the effort and maybe one should
invent Python lite that uses a simpler call mechanism :-O

> 
> > Another problem with loops could be reference counting.  I'm wondering
> > how often a reference count get's changed when running a loop ...
> 
> Not vastly more often than in regular code, I'd guess. It's true that
> executing
> 
> 1+1
> 
> spends longer twiddling refcounts than doing the work, but that's Python.
> 
> I can't decide which Peters-style ending I want here, so you're all
> getting two:
> 
> not-OO-functional-or-fast-but-still-great-ly y'rs
> it's-not-OO-or-functional-it's-Python-ly y'rs
> 


Markus
-- 
Markus Kohler  mailto:markus_kohler at hp.com