[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PROBE-FILE
- To: common-lisp@SU-AI.ARPA
- Subject: Re: PROBE-FILE
- From: Nick Gall <Gall@MIT-MULTICS.ARPA>
- Date: Fri, 12 Apr 85 00:21 EST
- In-reply-to: Message of 11 Apr 85 14:55 EST from "Scott E. Fahlman"
- Posted-date: 12 Apr 85 00:23 EST
Date: 11 April 1985 14:55 est
From: Scott E. Fahlman <Fahlman at CMU-CS-C>
Subject: PROBE-FILE
I've avoided stepping into this particular discussion (and probably will
regret doing so now) but it looks to me like it might be time to try to
close the issue, for now at least. Let me toss out the following
suggestions to see if they are acceptable to everyone:
1. It is allowable for a Common Lisp system to signal an error on probef
if the file name is malformed in some way, or if the file is not found
for other than the usual reasons.
2. Implementations that don't want to handle this with an error, perhaps
because they lack an error-handling system of sufficient power, can for
now do something compatible but non-portable about this, such as taking
a special keyword or returning an extra value describing what went
wrong.
3. We should try again for a clean, fully portable solution to this
problem after we have reached some consensus on a standard
signal/error-handling system. At that point, we'll be able to see much
more clearly whether this is a good way to deal with this sort of
situation.
-- Scott
I think the signalling of an error in the case of a namestring that is
syntactically illegal is an entirely separate issue that applies to most
of the file system interface function.
Many functions besides PROBE-FILE can take a namestring as an argument
(e.g., PATHNAME, OPEN, RENAME-FILE,DELETE-FILE). Nowhere does the CLRM
define what occurs if one of these functions is given a syntactically
illegal namestring.
Only PARSE-NAMESTRING is explicitly defined to signal an error "if the
[name]string does not consist entirely of the representation of a
pathname."
My suggestions are as follows:
1. The function PATHNAME be defined to signal an error if given a
syntactically illegal namestring.
2. The parameter names FILE, FILENAME, and THING be flushed and
replaced with PATHNAME.
3. Explicity state that all functions that take a PATHNAME argument
implicity apply the function PATHNAME to the argument.
This would mean that PROBE-FILE WOULD signal an error if given a
syntactically illegal namestring. Otherwise, if PROBE-FILE is given a
legal namestring, it should NOT signal an error if the pathname is
SEMANTICALLY illegal (e.g., non-existent dir.), I assumed this is what
TRUENAME was for. (If this is not the case, what IS the dif. between
PROBE-FILE and TRUENAME).