Re: why tail recursion matters and why Java isn't it, was Re: lisp performance was Re: problems with lisp

[David Herman <address@hidden>]

> This doesn't prove anything. In Scheme you're relying on a very 
> specialized feature of tail calls to be sure that your code is 
> efficient.

This was my first impression of proper tail recursion, too. It even 
felt like a violation of an abstraction boundary. But in fact, the 
opposite is true: the expectation that the runtime will blow its stack 
beyond a fixed depth of recursion is the violation. You should be able 
to use recursion without having to think about the runtime 
implementation (in fact, the R5RS requirement is simply that tail cails 
take up constant space; they don't dictate any particular 
implementation, so your runtime may use any number of techniques, such 
as trampolining, Cheney on the MTA, etc.).

> In both cases, you have to know the languages well to get your work 
> done to your satisfaction. In the Common Lisp case, I have at least 
> three options to express my intent - one of them is straightforward, 
> the other two are not.

A particular loop construct may be natural (for some definition 
thereof) for some problems, but not for others. With recursion and 
higher-order functions you can build your own loop constructs that fit 
the problem space better.

> Luke Gorrie mailed me this other solution.
>
> (mapcar 'car list)

Try doing that with iteration, mutation, and integer indexes and still 
convince yourself that a for-loop is more natural. :)

> I disagree. Programming language design should not be purely based on 
> the mathematical aesthetics of simplicity and generality. Programmer's 
> convenience is also important.
>
> To put it differently, it's important for what purposes your language 
> is designed. If you want to mainly prove properties about languages 
> then recursion is enough. If you want to be able to clearly express 
> your intentions then it's not.

If I understand this, you're making the assumption that the previous 
posters' motivations are pure language research and/or mathematical 
beauty. But the authors of "How to Design Programs" have a much more 
practical goal in mind: better programming, better design.

Dave