Re: Recursive file listing function - which one is best?



In article <1180982245.734528.289380@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
"Jeff M." <massung@xxxxxxxxx> wrote:

On Jun 4, 12:47 pm, Dan Bensen <randomg...@xxxxxxxxxxxxxx> wrote:
Jeff M. wrote:

Tail call elimination isn't mandated in Common Lisp.

Wow. I did not know that. Why on earth would it not be? It puts a new
light on things - and sucks.

You don't need tail-call conversion in a language that supports
iteration. As long as each nonterminal call makes only one recursive
call, it's easy to write the code imperatively.

That's a truism and doesn't matter. I could just as easily claim that
BASIC is Turing complete and can solve all problems that Lisp can
solve. But that's also a foolish statement. One uses the tools best
suited for any particular problem (hopefully, job req's withstanding).
Recursion is just very well suited to solve certain problems. The one
posed by the original poster is especially suited to recursion. Use
it.

Only if your directories have less files than the recursion limit.

(defun foo (files)
(if files
(cons (cons (first files)
'some-data)
(foo (rest files))))

? (foo (directory "/music/**/*.mp3"))
Error: Stack overflow on value stack.


Is that 'suited for recursion'? It is not. There are
people who have 'lots' of files in the file system
or even in one directory.

To avoid that in Common Lisp you'd write something like:

(defun foo (files)
(mapcar (lambda (file) (cons file 'some-data))
files))

Or use LOOP. Or something else.


Meh, I feel suckered into yet another retarded semantics "discussion"
on this newsgroup yet again...

To the original poster: enjoy Lisp! It's fun. It will change the way
you approach problem solving in programming. And take the time to do
exercises like the one you did, regardless of someone else giving you
the "one line" solution. You'll be better off for it. :)

Jeff M.

I think it is necessary not only to give simple advice
like 'this is the solution to your question',
but explain the various advantages and disadvantages.

For me c.l.lisp is NOT a repository of people writing code
for me, but it is a resource to understanding
Lisp programming. Understanding comes with discussions,
experiments, questions, different answers, different
ideas.

I think that's what makes comp.lang.lisp different. Some
discussions may be long-winded or look overly complicated,
but there are many people who are reading these posts
and trying to learn from the discussions. There are also
lots of people reading comp.lang.lisp without posting
here.

--
http://lispm.dyndns.org
.