Issue: PATHNAME-WILD (Version 2)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

I just added a few remarks in the Discussion.

-----
Issue:        PATHNAME-WILD
References:   Pathnames (pp410-413)
Category:     ADDITION
Edit history: 21-Jul-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  Some file systems provide more complex conventions for wildcards than
  simple component-wise wildcards. For example,

  "F*O" might mean:
    - a normal three character name
    - a three-character name, with the middle char wild
    - at least a two-character name, with the middle 0 or more chars wild
    - a wild match spanning multiple directories

  ">foo>*>bar" might imply:
    - the middle directory is named "*"
    - the middle directory is :WILD
    - there may be zero or more :WILD middle directories
    - the middle directory name matches any one-letter name

  ">foo>**>bar" might mean
    - the middle directory is named "**"
    - the middle directory is :WILD
    - there may be zero or more :WILD middle directories
    - the middle directory name matches any two-letter name

  The CL pathname model does not provide a way to represent such wildcards,
  which means, for example, that (MAKE-PATHNAME :NAME "F*O") cannot be
  recognized by portable code as containing a wildcard.

  CL code needs to at least be able to detect and possibly to manipulate
  such wildcard pathnames.

Proposal (PATHNAME-WILD:NEW-FUNCTION):

  Introduce the following function:

   WILD-PATHNAME-P pathname &optional field-key			[Function]
 
   Tests a pathname for the presence of wildcard components.
   If the first argument is not a pathname an error is signalled.
 
   If no field-key is provided, or the field-key is NIL, this function
   returns true if the argument pathname has any wildcard components.
   Otherwise, it returns false.
 
   If a non-null field-key is provided, it must be one of :HOST, :DEVICE,
   :DIRECTORY, :NAME, :TYPE, or :VERSION. In this case, it returns true
   if the argument pathname is wild in the indicated component. Otherwise,
   it returns false.

Test Case:

  #1: (WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD)) => T

  #2: (WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD) :NAME) => T

  #3: (WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD) :TYPE) => NIL

  #4: (WILD-PATHNAME-P (PATHNAME "S:>foo>**>")) => T   ;Lispm

  #4: (WILD-PATHNAME-P (PATHNAME :NAME "F*O")) => T ;Most places

Rationale:

  If the programmer can at least detect wild pathnames reliably,
  he can know to do something useful (give up, merge out the bothersome
  components, call DIRECTORY for a list of matching pathnames, etc.)

Current Practice:

  Presumably no implemenation supports the proposal exactly as stated.

  Symbolics Genera provides the ability to do
    (SEND pathname :WILD-P)
  which returns a value such as NIL, :NAME, :TYPE, etc. In the case
  that more than one field is wild, however, some information is lost.

Cost to Implementors:

  Many implementations probably have a substrate which is capable of this
  or something similar already. In such cases, it's a relatively small
  matter to add the proposed interface.

  Even in cases where an implementation doesn't have ready code, it's clearly
  better for the implementor to write that code once and for all than to ask
  each user of wildcarded code to write it (often more heuristically).

Cost to Users:

  None. This change is upward compatible.

Cost of Non-Adoption:

  Wild pathnames would continue to be mistaken for ordinary pathnames in
  situations which CL pathnames cannot represent.

Benefits:

  Portable user interfaces that prompt users for pathnames could more
  reliably detect wildcard pathnames and more easily guard against
  embarrassing behavior in such situations.

Aesthetics:

  This change would make some portable code less kludgey.

Discussion:

  Pitman supports PATHNAME-WILD:NEW-FUNCTION.

  It would have been possible for this function to have accepted
  a string as an argument (coercing it to a pathnames), but that
  would have entailed adding an optional host argument. We opted
  not to do this.

  There was some question about the name. The name PATHNAME-WILD-P
  suggests a ``slot'' of a pathname (like PATHNAME-HOST),
  while WILD-PATHNAME-P suggests a type (like INPUT-STREAM-P).
  The committee was split on what to call it. Since it is more
  like a type than a slot, the name WILD-PATHNAME-P was chosen.