functional programming

[Moshe Zadka]

On 25 Feb 2000, Denys Duchier wrote:

> > I won't say anything about C++ (what I'd like to say about it isn't
> > fit for prime time), but about Python, this is untrue: either the called
> > function has a reference to the object (in which case it won't be
> > finalized) or it can be deleted when the calling frame is deleted, in
> > which case the call to the destructor will *precede* the tail-call,
> > and still leave it in tail position.

<arguing that the optimization would change Python's semantics>
> It makes a difference whether the lock is released before the call to
> baz() or after.  I am by no means sanguine about keeping Python's
> finalization semantics, but it _is_ an issue that makes a difference.

Well, for one thing, it doesn't violate any of the language's guranteed
semantics. Any *sensible* programmer would explicitly close the lock
after calling baz(), and then baz() would be in a tail-position no longer.
(Actually, any sensible programmer would do it in a finally clause).
Otherwise, if an exception is raised, the lock is still locked, which is
problematic (the code catching the exception would have a hard time
knowing if it is locked, etc.) So, since the only example you give is of a
coding practice to shady it *deserves* to lose, I take it you agree with
me <0.5 wink -- but you'll have to find a better example>

arguing-is-fun-ly y'rs, Z.
--
Moshe Zadka <mzadka at geocities.com>. 
INTERNET: Learn what you know.
Share what you don't.