[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: why tail recursion matters and why Java isn't it, was Re: lisp performance was Re: problems with lisp
> 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
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.