Helu
CMUCL has a nifty search-list extension to pathnames[1]
<URL:http://common-lisp.net/project/cmucl/doc/cmu-user/extensions.html#toc52>
which lets you specify a bunch of directories to to look up a file
in. [See the last last paragraph in the full quote below]
Did this concept originate with CMUCL?
Did any other lisp (other than SCL) implement this feature?
I have seen some defsystem facilities that included a :PATCH-DIRECTORY
option to specify alternate sources. I believe SCL extended its logical
pathname facilities to allow a list of potential paths for each
translation.
I'm looking for experience at how one can specify and use multiple
search directories when dealing with pathnames. I'd love to have a
portable implementation. Would an approach like SCL's, using (SETF
LOGICAL-PATHNAME-TRANSLATIONS) accord with the spec?
--
Madhu
[1]
,---- From cmu-user/extensions.html [Sec.2.16.4] :Search Lists:
|
| They serve a function somewhat similar to Common Lisp logical
| pathnames, but work more like Unix PATH variables. Search lists are
| used for two purposes:
|
| - They provide a convenient shorthand for commonly used directory
| names, and
|
| - They allow the abstract (directory structure independent)
| specification of file locations in program pathname constants (similar
| to logical pathnames.)
|
| Each search list has an associated list of directories (represented as
| pathnames with no name or type component.) The namestring for any
| relative pathname may be prefixed with ``slist:'', indicating that the
| pathname is relative to the search list slist (instead of to the
| current working directory.) Once qualified with a search list, the
| pathname is no longer considered to be relative.
|
| When a search list qualified pathname is passed to a file-system
| operation such as open, load or truename, each directory in the search
| list is successively used as the root of the pathname until the file
| is located. When a file is written to a search list directory, the
| file is always written to the first directory in the list.
`----
On Jun 9, 7:13 am, Madhu <·······@meer.net> wrote:
> Helu
>
> CMUCL has a nifty search-list extension to pathnames[1]
> <URL:http://common-lisp.net/project/cmucl/doc/cmu-user/extensions.html#toc52>
>
> which lets you specify a bunch of directories to to look up a file
> in. [See the last last paragraph in the full quote below]
>
> Did this concept originate with CMUCL?
UNIX PATH environment variable for searching for executable files.
VPATH in some versions of make to search for prerequisite files for a
target.
* Kaz Kylheku <····································@t54g2000hsg.googlegroups.com> Wrote on Mon, 9 Jun 2008 13:11:25 -0700 (PDT):
| On Jun 9, 7:13 am, Madhu <·······@meer.net> wrote:
|> CMUCL has a nifty search-list extension to pathnames[1]
|> <URL:http://common-lisp.net/project/cmucl/doc/cmu-user/extensions.html#toc52
|>
|> which lets you specify a bunch of directories to to look up a file
|> in. [See the last last paragraph in the full quote below]
|>
|> Did this concept originate with CMUCL?
|
| UNIX PATH environment variable for searching for executable files.
|
| VPATH in some versions of make to search for prerequisite files for a
| target.
Neither of these mechanisms support specifying paths as
$PATH/path/to/file (to be expanded by the system at runtime). I think
this is the key innovation. Of course I believe PATH served as
inspiration, but this is an easily overlooked difference -- Using UNIX
shell notation, for the case of writing files:
TMPSEARCHLIST=/root/tmp/:/var/tmp:/tmp
echo foo > $TMPSEARCHLIST/subdir/tmpfile
would write root/tmp/subdir/tmpfile if /root/tmp/subdir/ existed. otherwise
it'd write /var/tmp/subdir/tmpfile if /var/tmp/subdir existed, otherwise
it'd write /tmp/subdir/tmpfile if /tmp/subdir existed, otherwise it'd
fail
Did any other lisp support this sort of thing?
--
Madhu
Madhu <·······@meer.net> writes:
> CMUCL has a nifty search-list extension to pathnames...
> ...I'd love to have a portable implementation. Would an approach like
> SCL's, using (SETF LOGICAL-PATHNAME-TRANSLATIONS) accord with the
> spec?
The spec for LOGICAL-PATHNAME-TRANSLATIONS says that the translations
is a list of lists of at least two arguments, and an implementation
may define the meanings of any additional elements. So it would be
conforming for an implementation to take translations with more than 2
elements, and treat the REST of each translation as a search-list.
Otherwise, it's not actually hard to come up with search-list
functionality, if you're willing to have it exist as a layer above
pathnames per se:
(defvar *search-lists* (make-hash-table :test #'equalp)
"A case-insensitive mapping of search-list names to lists of pathnames.")
(defun search-list (thing)
"Coerce THING to a search-list."
(etypecase thing
(list thing)
(string (gethash thing *search-lists*))))
(defun (setf search-list) (list string)
"Assign LIST to be the search named by STRING."
(check-type string string)
(check-type list list)
(setf (gethash string *search-lists*) list))
(defun open-using-search-list (pathname search-list
&rest open-keys &key (direction :input))
"Open PATHNAME, using successive elements of SEARCH-LIST as defaults."
(let ((search-list (search-list search-list))
(pathname (pathname pathname)))
(ecase direction
;; There's some inherent arbitrariness to the semantics here, of
;; course: e.g., should we silently ignore errors coming from one
;; of these OPEN calls?
((:input :io)
(loop for defaults in search-list
thereis (apply #'open
(merge-pathnames pathname defaults)
:if-does-not-exist nil open-keys)
finally (error "Can't open ~A using ~A." pathname search-list)))
((:output :probe)
(apply #'open (merge-pathnames pathname (first search-list))
open-keys)))))
;; Other functions in the CL file system API could be filled in, too,
;; if one feels like deciding their semantics.
--
RmK
Madhu <·······@meer.net> writes:
> Helu
>
> CMUCL has a nifty search-list extension to pathnames[1]
> <URL:http://common-lisp.net/project/cmucl/doc/cmu-user/extensions.html#toc52>
>
> which lets you specify a bunch of directories to to look up a file
> in. [See the last last paragraph in the full quote below]
>
> Did this concept originate with CMUCL?
> Did any other lisp (other than SCL) implement this feature?
Emacs Lisp has load paths that are searched. This pre-dates Common Lisp
and CMUCL.
--
Thomas A. Russ, USC/Information Sciences Institute