I think this is one of the failings of Common Lisp. For the example of snarfing a file into a single string, here are some examples of the fun you can have:

http://www.emmett.ca/~sabetts/slurp.html http://www.tfeb.org/lisp/obscurities.html#SNARFING-FILES http://www.codecodex.com/wiki/index.php?title=Read_a_file_in... http://www.cl-user.net/asp/html-docs/process-file-snippset

According to the first link, this turns out to be the most efficient and most idiomatic way to do it:

    (defun slurp-stream5 (stream)
      (let ((seq (make-array (file-length stream) :element-type 'character :fill-pointer t)))
        (setf (fill-pointer seq) (read-sequence seq stream))
        seq))

Makes sense once you know what all the pieces mean, but not the first thing a new Common Lisp programmer will think of. Then, in the SNARFING-FILES link, turns out it's not correct for all files, anyway, and the "correct" version is considerably longer.

EDIT: Oops. The code I pasted DID include the proper file length check (at the cost of reading into an array of characters, instead of a string). So ignore the last sentence of my (unedited) post.

This is why there's such a thing as libraries. When I want to read a file, I say (slurp path).

Which library is that?

This is mostly just a list of features without context. I'm sure "ellipsize" really helps for ... something. But I don't know what it is, sadly, because I don't know arc.

Shouldn't posts like this be useful for people who aren't part of the cult already? :)

"The whole-file I/O routines, starting with readfile, are a great idea - usually what you want in a file is to read the whole thing. There should be one (file?) for reading the whole file as a string too."

This is easy in blub, too: http://commons.apache.org/io/api-release/org/apache/commons/...(java.io.File) , although that URL gets incorrectly parsed by PG's buggy Arc code. :)