Retry, IMSSS->SCORE mail down a few days; Flush implicit catch frames

[Robert Elton Maas <REM@IMSSS.STANFORD.EDU>]

Date: Sat, 28 Dec 1985 22:24:00 -0000
From: Rem@IMSSS
Subject: I favor flushing implicit catch frames except where appropriate
To:   edsel!eb%su-navajo.arpa@SCORE
cc:   COMMON-LISP%SU-AI@SCORE

Your message is very interesting. It sounds like CL in forcing the
availibility of RETURN-FROM just about everywhere in the language has
accidently forbid efficient tail recursion except when an optimizing
compiler has gone around and flushed unneeded RETURN-FROM (CATCH) frames.
If you are correct, I would favor flushing this default behaviour of
CL, instead requiring programmers to say explicitly when some PROG or
LET might need the RETURN-FROM capability.

When I want to do a non-local return, I first think of THROW/CATCH, which
is completely general, and not of RETURN-FROM. Something like 99% of
PROGs and LETs et al are simple, don't need a non-local return mechanism.
Let's take a survey. Is there anyone who programs in such a way that any
significant fraction of PROGs or LETs et al make use of RETURN-FROM?
Is there anyone would have to rewrite a lot of code if RETURN-FROM frames
weren't implicit everywhere in the language. Would anyone object to
requiring explicit CATCH where nonlocal return frames are desired?

P.S. Normally all those extra frames are useful during debugging, so
when something bombs out you can look up the recursion stack and see
all the calls and jcalls still on the stack instead of just the calls
(notation: jcall = tail-recursion, call = true-recursion). But often
one has an interpreted function that is highly recursive but where
those extra frames aren't useful and cause stack overflow, so I can see
the value in being able to disable the creation of tail-recursion frames,
and I second the motion to maybe flush them.
-------