Jonathan Simms <[EMAIL PROTECTED]> writes: > Lisp. The > most recent experience I've had was working dilligently through Mr. > Seibel's > "Practical Common Lisp". From the outset, I kept thinking, "Yes, this > is all > well and good, but when do we actually get to *do* something?" I > strengthened > my resolve, and pushed ahead to chapter 14 "Files and File I/O" thinking > "Surely, we will reach files and I'll get to do something fun, like > copy a > something from one place to another, or (dare I say?) traverse a > directory > tree." > > Alas, I was somewhat disappointed.
I'm not sure this is what you mean, but Peter discusses directory traversal in Chapter "15. Practical: A Portable Pathname Library", see section "Walking a Directory Tree" and function FAD:WALK-DIRECTORY: http://www.gigamonkeys.com/book/practical-a-portable-pathname-library.html The function is also described here: http://weitz.de/cl-fad/#walk-directory As for copying, here is an example of copying streams taken from the SB-EXECUTABLE SBCL module (`contrib/sb-executable/sb-executable.lisp' in the source tree): (defvar *stream-buffer-size* 8192) (defun copy-stream (from to) "Copy into TO from FROM until end of the input stream, in blocks of *stream-buffer-size*. The streams should have the same element type." (unless (subtypep (stream-element-type to) (stream-element-type from)) (error "Incompatible streams ~A and ~A." from to)) (let ((buf (make-array *stream-buffer-size* :element-type (stream-element-type from)))) (loop (let ((pos (read-sequence buf from))) (when (zerop pos) (return)) (write-sequence buf to :end pos))))) > From PCL: > > "I'll discuss the standard functions here and point out the ones that > suffer > from nonportability between implementations. In the next chapter you'll > develop a pathname portability library to smooth over some of those > nonportability issues." [...] > bit incredulous, "What do you mean? *I* have to write a compatability > layer? [...] > directly related to my poor, unenlightened, non-Lisp world. I want to > be able > to do that without having to know how the 5-10 popular flavors of Lisp > implemented PATHNAME differently. I read PCL's chapter on the CLOS Common Lisp has a long and complex history. When it was designed, the computing world had much more diversity than now. In the case of pathnames, Common Lisp had the ambition of providing a powerful abstraction over the way the different file systems managed file names at the time. One may not agree with these design decision. But it would be useful to know at least understand something on the historical context within which certain design decisions were taken. > and writing Successful Lisp (nudge nudge, wink wink). First is the > myraid of > inconsistencies between the implementations of Lisp. It struck me > that this is > not too dissimilar from my experience in trying to write cross-browser > Javascript. Thankfully, there is the prototype project > (http://prototype.conio.net) that is gaining wild popularity because it While I agree in principle that it would be good to have a unified Lisp implementation--or fewer ones--as happens with languages like Python and Perl, I'm afraid this isn't going to happen anytime soon. It takes much more than gardening, it requires full blown genetic engineering. There are both technical and non-technical reasons for the existence of different Common Lisp implementations, some of which were discussed in comp.lang.lisp. I personally don't feel like dismissing them lightly. When there is general agreement over a possible unification, e.g. the one between CMUCL and SBCL, the amount of complex work required from experienced programmers is so great that real life and limited resources kick in. I personally have a much less ambitious, short-term goal: to smooth out the differences among existing systems and libraries in such a way that the inconveniences are reduced or acceptable. > The second issue seems to me to be that there isn't a simple, > consistent, and > unix-y way to deal with the operating system (if I'm terribly wrong Again, this is a consequence of the historical context in which Common Lisp was designed. See the pathnames example above. But if you are only interested in Unix, things may be simpler: you can just pick the Lisp implementation that best fits your needs, and stick with it. > this, I plead ignorance). It would be very helpful to me in learning > Lisp if > there were a library I could use that would make it easy to use my > operating > system as subject matter, something that would make it as easy and as > natural > to write bash-style scripts in Lisp as it would be to write them > in...well... > bash. You may check: ShellScripting http://www.cliki.net/ShellScripting Osicat http://common-lisp.net/project/osicat/ SB-POSIX SBCL contrib module Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log _______________________________________________ Gardeners mailing list [email protected] http://www.lispniks.com/mailman/listinfo/gardeners
