declarations summary

[Alex Martelli]

Michael Tobis <mt at 3planes.com> wrote:
   ...
> .x = 1
> .def foo():
> .   if False:
> .      global x
> .   x = 2
> .foo()
> .print x
> 
> prints "1"

Wrong:

>>> x = 1
>>> def foo():
...   if False:
...     global x
...   x = 2
... 
>>> foo()
>>> print x
2

And indeed, that IS the problem.

> Pythonistas appear to be averse to any declarations (in the sense of
> compiler directives) besides "global".

Many of us consider ``global'' a nasty wart, too.

> Anyway, it's this sort of reference-modifier that's at issue here,

You can play with references as much as you like, as long as they're
*COMPOUND* names (attributes, or even, if you with, items).  Just leave
*BARE* names alone, and nobody will jump all over you.

> It's not difficult for me to imagine at least two other things I'd want
> to do with references: 1) make them immutable (making life easier for
> the compiler) 2) make them refer only to objects with certain
> properties (strong duck-typing).

Look at Enthought's ``Traits'' for some highly developed infrastructure
along these lines -- for *COMPOUND* names only, of course.  No ``making
life easier for the compiler'', but for example ease of generation of
forms and other view/controller implementations from a model, etc.

If you're keen to hack on the compiler to take advantage of such
information for code generation purposes, your experimentation will be
easier once the AST branch is folded back into the 2.5 CVS head; if it's
not about code generation but just runtime (so not really about the
compiler but rather about the virtual machine), pypy (see codespeak.net)
may help you similarly, already today.  If you're not keen to hack,
experiment, and prove that dramatic speedups can be obtained this way,
then I doubt that musing about ``helping the compiler'' in a purely
theoretical way is gonna do any good whatsoever.


> On the other hand, I think compiler writers are too attached to
> cleverly divining the intention of the programmer. Much of the effort
> of the compiler could be obviated by judicious use of declarations and
> other hints in cases where they matter. Correct code could always be

Ah, somebody who's never hacked on C compilers during the transition
from when ``judicious use of 'register' '' (surely a classic example of
such an "other hint") was SO crucial, to where it doesn't matter in the
least -- except that it's an ugly wart, and the clutter stays.

Used to be that C compilers didn't do register allocation with any skill
nor finesse, but did let you give a hint by using "register" as the
storage class of a variable.  Smart programmers studied the generated
machine code on a few architectures of interest, placed "register"
appropriately, studied what changes this made to the generated code, and
didn't forget to check on all different machines of interest.

Most C programmers just slapped "register" where they GUESSED it would
help, and in far too many cases they were horribly wrong, because
intuition is no good guide to performance improvement; I have witnessed
examples of code where on certain machine/compiler combinations
inserting a "#define register auto" to disable the GD ``register'' made
some functions measurably FASTER.

Then "graph-coloring" register allocators came into their own and in the
space of a few years ``register'' blissfully became just about
irrelevant; nowadays, I believe all extant compilers simply ignore it,
at least in suitable optimization mode.

Of course, for backwards compatibility, "register" remains in the
language: total, absolute, absurd deadweight -- one extra little
difficulty in learning the language that has absolutely no reason to
exist, gives zero added value, just clutters things up to no purpose
whatsoever.

So much for the ``judicious'' use of performance hints: it just doesn't
happen enough in the real world, to put up with the aggravations until
compiler technology has gotten around to making a certain hint
irrelevant, and the totally useless conceptual and coding clutter
forevermore afterwards.

Those who can't learn from history are condemned to repeat it.  Maybe
some of us just know some history better (perhaps by having lived it)
and don't need yet another round of repetition?

Optional declarations to ease compiler optimizations were at the heart
of Dylan, and looked like a great idea, but Dylan's success surely
wasn't such as to enourage a repeat of this ``soft typing'' experiment,
was it now?  Of course, it's always hard to pinpoint one reason out of a
language's many features -- e.g., Dylan had macros, too, maybe THOSE
were more of a problem than soft-typing.

In theory, I do like the idea of being able to give assertions about
issues that a compiler could not reasonably infer (without analyzing the
whole program's code, which is another idea that never really panned out
for real-life programs as well as one might hope), and having a mode
where those assertions get checked at runtime and another where the
compiler may, if it wishes, rely on those assertions for code
optimization purposes.  In practice, having never seen this
theoretically nice idea work really WELL in real life, despite it being
tried out in a huge number of ways and variations many, MANY times, I'd
have to be convinced that a particular incarnation is working well by
seeing it make a truly impressive performance difference in some
prototype implementation.  AST-branch for the compiler side, and pypy
for the runtime side, are developing in good part just in order to ALLOW
easy experimentation, by coding only Python (and maybe generating some
pyrex, if the point of some idea is making some sparkling machinecode).

Intuitions about performance are far too often completely off the mark:
performance effects just NEED to be shown as working well in practice,
before any credence can be put into reasoning that this, that or the
other tweak "should" speed things up wondrously.

> socks off yet again, but I can't see counting on it. So the successor
> to Fortran (presuming it isn't C++, which I do presume) may be
> influenced by Python, but probably it won't be Python.

You appear to assume that Fortran is dead, or dying, or is gonna die
soon.  I assume Mr. Beliavski will do a great job of jumping on you for
this, so I can save the effort of doing do myself;-).


Alex