requiring proper tail recursion

[Kent Pitman <kmp@harlequin.com>]

I accept Guy's definition as a fair re-casting of what I wrote,
although I do lamentably have one philosophical quibble lingering:

Prior to the assertion that the tail call must be optimized / must not
be pessimized, the choice to not do the thing Scheme does is value neutral.

It is only once you require that the language do the optimization /
not do the pessimization that you find it very strongly important that
implementations support this.

The premature introduction of the concept of pessimization in the absence of
an understanding of the patterns of use to be expected seems ill advised.
i.e., people will use it a lot because you later require it, and it's only a 
pessimization because of that fact, not because it's a fundamental truth of
the universe.

Programming languages are sets of choices we make--no choice comes for
free.  We like to think we make choices that work well together, and I
am not arguing against the choice per se--I am, however, concerned
about any presentation of the choice that suggests there was no other.

I am mildly concerned that if this (admittedly fun) wording is chosen,
people will think (falsely) that there is no good reason not to have
it work this way and that other languages are capricious and reckless
and bad in their desire to retain a strict stack model.  In fact,
Scheme's aggressive tail call elimination can be a barrier to stack
debugging, and some languages separate iteration from recursion
precisely in order to allow the user to express when stack information
ought usefully be retained and when it ought not.  In particular, a
Common Lisp oriented model, augmented slightly to define the
interactions between declarations requesting high debuggability and
high optimization of space usage would presumably allow programmers to
gracefully shift between these two approaches at different points in
the same program (since one global compiler switch is too blunt to
really do the job), and so one could have the best of both worlds.
I'm not suggesting that Scheme become like CL, but I am suggesting
that Scheme in its zeal to define its view as good and other views as
bad could again end up having declared itself the winner without
actually being in the best of all possible worlds by at least some
accounts.

As such, I'd like a value neutral term like "elimination" instead of 
"optimization/pessimization".  (If you don't like my reason for asking for it,
then consider it a blow for internationlization/internationalisation, so we
don't have to fight over the "z"/"s" in optimize/pessimize. :-)
This would, of course, require some additional rewriting.

Further, if "well-loved" is going to be used in here [again begging 
definitional questions that led us to open this set of paragraphs for
rewording :-], I'm almost tempted to ask the wording be extended to say

 "... a widely used and
  well-loved programming idiom in the Scheme language that
  defeats the widely used and well-loved program idiom of stack debugging
  common to other languages."

I think emphasizing this kind of back and forth in decision-making would
humaniz/se Scheme in a good way.