[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: PATHNAME-WILD (version 5)
- To: Sandra J Loosemore <email@example.com>, David N Gray <Gray@DSG.csc.ti.com>
- Subject: Re: Issue: PATHNAME-WILD (version 5)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 12 Jun 89 18:24 EDT
- Cc: CL-Cleanup@sail.stanford.edu
- In-reply-to: <8905252006.AA09216@defun.utah.edu>, <2822171220-15473020@Kelvin>
I'm having trouble finding the time to write up revised versions
of these issues, based on your comments, but here is an acknowledgement
of your comments and some responses.
Date: Thu, 25 May 89 14:06:18 MDT
From: firstname.lastname@example.org (Sandra J Loosemore)
I don't understand what all the arguments to TRANSLATE-PATHNAME are
for. I guess that this function is intended to be a merging operation
that fills in wildcard components in one pathname with matching
components from another pathname, but I don't understand why you need
to pass in two wildcard pathnames instead of one,
It's not a merging operation, it's a translating operation. The two wildcard
pathnames tell you what translates to what. I suppose that's not any clearer
than what the issue writeup said; I'll try to improve the way this is
described, if I can find the time. I take it the example that was given
in the writeup didn't help? Could you constructively criticize it?
or what reversibility really implies.
Reversibility is easy, it means it obeys the invariant given in the
proposal. The hard question is what does irreversibility really imply
(i.e. why don't we just make it reversible all the time?) and that's hard
because it's implementation-dependent. The basic idea is that Common Lisp
can't dictate any particular wildcard matching and translating algorithm,
because every file system has its own idea of what's right, and we'd get
into a religious war if we tried to dictate some particular algorithm.
I got kind of lost reading the
description of this function -- isn't there a more concise way to
state what is going on?
I'll look for one. Thanks for the feedback.
Date: Tue, 6 Jun 89 19:27:00 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
I was worried that permitting (WILD-PATHNAME-P <path> :HOST) implied
that the host component might be wild, which is impossible in our
implementation. But I see that proposal
PATHNAME-COMPONENT-VALUE:SPECIFY clarifies that the standard does not
require support for wild hosts. So you might want to mention here that
(WILD-PATHNAME-P <path> :HOST) is allowed just in case some
implementation might support wild hosts as an extension.
I'm not sure how much of PATHNAME-COMPONENT-VALUE to copy into
PATHNAME-WILD; my preference is to copy as little as possible, to
minimize the chance for creating inconsistencies. Perhaps the rationale
section should just say that WILD-PATHNAME-P might always return NIL in
some implementations or something.
> Current Practice:
The Explorer also supports the messages :WILD-P (although it only
returns NIL or T), :NAME-WILD-P, etc., :TRANSLATE-WILD-PATHNAME, and
> The clarification is current practice as far as the authors are aware.
> If some implementations are found that specify a meaning for wildcard
> pathnames as arguments to these functions, this proposal should be changed
> to say that the consequences are unspecified rather than signalling an error.
The Explorer permits DELETE-FILE on a wild pathname, meaning to delete
all files that match.
I don't think this should be a mandated feature, but we can add it to current
practice. Do you think this feature of the Explorer is good or a wart? I.e.
would you like the proposal to say that the consequences are unspecified, or
would you like the proposal to require the Explorer to change?