functional programming

[Tim Peters]

[François Pinard]
>>> What would be the advantages of using a "functional" Python,
>>> as per your definition?  I mean, of course, in practice?

I'll toss one in, since I don't think anybody else mentioned it yet:
functional programs *can* be much easier to reason about.  NeelK nearly said
as much in the case of threaded programs, but it applies to single-threaded
programs too.  Not long ago Billy mentioned an especially <wink> pure
functional language called Joy, and reading the Joy papers should give a
quick feel for how powerful and natural reasoning can be in a language
aiming at that.  OTOH, Joy is useless <wink>.

[Moshe Zadka]
>> None. But it would be cool to have tail recursion, which could probably
>> be implemented in a post-Stackless world.

[bjorn]
> Maybe I'm dense, but what is stopping us from implementing tail call
> optimization (of which tail recursion is just a special case) with the
> current Python implementation.  Identifying a call in a tail position
> is a simple static analysis that isn't affected by Python's dynamicity (is
> that a word?).  Once they're identified you only need to translate a
> call to a jump instead of a push return address and jump.  There is no
> semantic change to Python.

I doubt Python will ever do this, not because of implementation reasons, but
for a combo of two and a half other reasons:

1. Guido doesn't want to support functional styles in Python; or, more
   accurately, wants not to support them <wink>.

2. Python tries to give users (at least those who bother to read the
   Reference Manual <wink>) a clear model for "what happens" at runtime.
   Explaining language semantics by explaining how the implementation
   works is frowned upon in many respectable circles, but in my
   experience is the only approach most users can actually grasp (no,
   a meta-circular interpreter is right out the window):  it's efficient
   of the user's time, and doesn't lie (except when it does -- in which
   case it points to a bug in the docs and/or the implementation).
   Magical optimizations work against that.

2.5. One great thing that shakes bugs out of Python code is that it
   raises an exception whenever it has a reasonable doubt about the
   code you told it execute, and a key part of making that *usable*
   is Python's never-lies complete stack trace.  If A calls B tails
   calls C tail calls D blows up, I damn sure don't want a traceback
   claiming that A called D directly.  I want to get a traceback object
   with the full chain intact, and I want to crawl up that chain to
   examine the state of the locals in B and C at the time they made
   their calls.  Optimize intermediate frames away, and tracebacks
   would become much harder to decipher.

the-state-of-things-that-blow-up-is-as-important-as-the-
    state-of-things-that-don't-ly y'rs  - tim