functional programming

[Denys Duchier]

Steve Holden <sholden at bellatlantic.net> writes:

> I was thinking more of the need for stack traceback when errors were
> detected.  I agree that a call at the end of a try block is not a
> tail call.  I am just concerned that tail call optimization would lose
> important debugging context unless you substitute some mechanism which
> retains the required information, which would defeat the point of the
> optimization.  Uncaught exceptions are handled at main level, and
> need full dynamic context.
> 
> Or have I missed something?

No, you are quite correct, but your concern is more about error
reporting (for debugging purposes) than about exception handling.  In
defense of tail call optimization, I might (very cautiously) offer the
following 2 arguments:

* as I believe you go on suggesting in another message, if one regards
  tail call optimization as _just_ an optimization, then nothing stops
  you from turning it off when debugging.

* tail call optimization is less damaging to debugging than is
  commonly believed.  The reason is that you only loose those
  intermediate frames where what is being computed no longer (locally)
  matters (or else they would not be a tail calls).

  Personally, I rather like getting just the highlights in my
  tracebacks and I have never come across a case where the lost
  information would have made a significant difference.  A non-expert
  programmer might feel differently.

  on the other hand, continuations are hell to debug no matter what :-)

The point, however, is moot since, as I suggested previously, the
finalization semantics of Python (much like that of C++) are not
easily reconciled with tail call optimization.

Sincerely,

-- 
Dr. Denys Duchier			Denys.Duchier at ps.uni-sb.de
Forschungsbereich Programmiersysteme	(Programming Systems Lab)
Universitaet des Saarlandes, Geb. 45	http://www.ps.uni-sb.de/~duchier
Postfach 15 11 50			Phone: +49 681 302 5618
66041 Saarbruecken, Germany		Fax:   +49 681 302 5615