Re: Issue: PATHNAME-WILD (version 5)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

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: sandra%defun@cs.utah.edu (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
    :PATHNAME-MATCH.

Will add.

    >   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?