[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Probe-File and proposed extension.
- To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
- Subject: Probe-File and proposed extension.
- From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
- Date: Tue, 9 Apr 85 20:37 EST
- Cc: common-lisp@SU-AI.ARPA, greek@DEC-HUDSON.ARPA
- In-reply-to: <RAM.12101610106.BABYL@CMU-CS-C.ARPA>
Date: Mon, 8 Apr 1985 18:29 EST
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
The point about relative pathnames is the following: When you
actually write a file, Open resolves any relative pathname down to an
absolute pathname. Any implementation that allows writing relative
pathnames must have some way to map the relative pathname to an
absolute pathname. This mapping is not necessarily the same as merge
pathnames, and in any case, there is no way in Common Lisp to
determine what the defaults are.
Well, the defaults for MERGE-PATHNAMES are whatever the program wants to
pass to merge-pathnames as an argument. I would hope that if OPEN has to
call MERGE-PATHNAMES, it would use *DEFAULT-PATHNAME-DEFAULTS*. But this
is moot since by relative pathnames you meant something different than I:
In Spice Lisp, when you open a file for write, Open first looks
for any file with that name on the default search list, and if found,
overwrites it, otherwise it creates a file in the current directory.
I will argue that this is the right semantics in our implementation,
and it is clearly implementation dependent.
Regardeless of the error issue, it would be useful to be able to
default a pathname for output in this fashion.
I see. This is not covered by the generic file-system model, but that
doesn't mean there is anything wrong with it. You need an interface to
this implementation-dependent feature, and the question is, should the
interface be defined in an implementation-independent way? Looked at
that way, the proposal for a :direction keyword to PROBE-FILE seems
pretty reasonable. Now that I understand it, this seems reasonable to
me, and perhaps it's time for you to make an explicit proposal.
On the other hand, you could always just add a function to Spice Lisp
that is just an implementation-dependent interface to Accent. Trying
to do file-system-related things in an implementation-independent way
can often be very tricky. I know of at least one file system that would
have some difficulty implementing this feature (specifically, getting the
version number right), although it probably wouldn't be impossible.
This should go on any lists that are being kept of proposed language
enhancements and clarifications.
As for the error issue, Spice Lisp currently does exactly what you
suggest. A user complained that this was not what the manual said it
should do. I tried both the Dec-20 Clisp and the Kyoto Common Lisp
implementations, and they both refused to signal errors, no matter
what garbage you gave them. I decided at this point that the issue
was unclear, but that the Spice Lisp implementation was probably
I think the Spice Lisp implementation is right. I don't think any
implementation without an error-handling system can be used as a fair
test of the circumstances in which PROBE-FILE should signal an error.