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
.



Relevant Pages

  • Re: "C-like" syntax for Lisp in less than 100 lines of code
    ... function for the Fibonacci series. ... that Lisp has no point, it is a toy language for teaching recursion. ... :-) I am guilty of liking these toys as well. ...
    (comp.lang.lisp)
  • Re: Making Lisp popular - can it be done?
    ... “hack” for recursion. ... We already have to think about how to do tail ... (recur (dec n) ... experience with implementing Lisp, ...
    (comp.lang.lisp)
  • Re: kernel stack challenge
    ... > infinite loop, and eventually ... Separate logical copy of LISP program is for each ... subsystem we protect. ... > recursion is at all interesting or useful.... ...
    (Linux-Kernel)
  • Re: How to make mod_lisp faster than php?
    ... In the Lisp group, the first fellow will answer, "I know my opinion, ... There seem to be various levels of acceptance of deep recursion ... It's possible that Scheme is here because a standard implementation of call/cc which puts stack frames on the heap yields this property. ... I think that implies tail recursion, ...
    (comp.lang.lisp)
  • Re: Beginners Question on an exercise from Grahams ACL
    ... > just been taught and to exercise my brain on them - not with some other ... Recursion might be more worthwhile as a separate item to learn, ... than binding up lisp and recursion into a single package of pain. ... Alternate places than lisp materials might teach it better, ...
    (comp.lang.lisp)