other python ideas

[Douglas Alan]

"Alex Martelli" <aleaxit at yahoo.com> writes:

> Definitely -- but you were proposing to "remove excessive
> flexibility" in order to enable code-generation improvements,
> so the "negative consequences" were more or less ensured --
> either an outright loss of flexibility (which, while you
> may consider it "excessive" for your purposes, is put to
> use by others), or addition of language features (so, less
> simplicity) to enable specification of what 'flexibility'
> may be 'removed' under what circumstances.

> So, the overall modification might either hurt or help --
> given that there are both pluses and minuses.  This makes
> it important (as part of the study of the inevitable
> trade-off) to evaluate how "positive" the pluses might be.

You are quite right here in all regards.  It behooves the designers of
a language to consider these issues carefully.  The trade-offs are
often far from obvious.  I think I can confidently assert, however,
that it is often the case that a little more complexity in the
mechanisms for allowing the programmer to specify what flexibility
will and won't be used in a program often lead to significantly
reduced complexity in the implementation of an optimizing compiler.
Complexity of the language should not be the only practical concern --
complexity of implementations also needs to be considered.  If this
were not the case, Python would have had an optimizing compiler long
ago.

Given that I hear many people clamor for more efficient scripting
languages, and more efficient implementations of Python in specific,
and because I can see the usefulness myself of such implementations, I
believe that making a language a *bit* more complicated in exchange
for greatly higher performance in an implementation that is ever
likely to be implemented, is a very worthwhile trade-off.

> Alternatively, one might leave all the flexibility in, and pay for
> fast code (to be generated only at need) in terms of a (perhaps big,
> complex, slow) optimizing compiler able to brilliantly infer types,
> etc, etc.

That is almost certainly true, as the compiler for Self demonstrated.
Implementing such a compiler seems to be something of a monumental
task.

> Stalin, at ftp://ftp.nj.nec.com/pub/qobi/stalin.tar.Z (I suspect
> http://packages.debian.org/testing/devel/stalin.html may be more
> up to date), is of course among the interesting studies in
> optimizing compilers for dynamic languages;

Thanks for the pointer.  That is indeed interesting.

|>oug