[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Retry, IMSSS->SCORE mail down a few days; Flush implicit catch frames
- To: REM%IMSSS@SU-SCORE.ARPA
- Subject: Retry, IMSSS->SCORE mail down a few days; Flush implicit catch frames
- From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
- Date: Mon, 30 Dec 85 15:33:21 EST
- Cc: COMMON-LISP@SU-AI.ARPA, edsel!eb@SU-NAVAJO.ARPA
- In-reply-to: Msg of 1985 Dec 29 23:21:04 PST (=GMT-8hr) from Robert Elton Maas <REM at IMSSS.STANFORD.EDU>
Date: 1985 December 29 23:21:04 PST (=GMT-8hr)
From: Robert Elton Maas <REM at IMSSS.STANFORD.EDU>
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.
As GJC correctly points out, Scheme has always had a lexical catch (i.e.
block/return) which is implementable in such a way that catches incur no
net stack growth, and no static code analysis is needed. The usual way
to do this allocates the control point (either a stub pointing into the
control stack, or the entire control stack) in the heap, but there are
more or less hairy alternative implementation strategies which do less
heap allocation (none, most of the time). I don't think this problem is
much different from that of allocating storage for lexical environments,
which if not done carefully also threatens tail recursion.
So tail-recursion is not a reason to flush implicit blocks. (I can
think of other reasons, but that's not the point.)