Re: RFC: operating on filenames which look wild

[<don...@is...>]

In response to this

  How about representing patterns more general than the keywords
  mentioned in the spec as lists containing strings and keywords?  
  Or even some list representation of regexps?

Sam wrote PTC, which sounds like an invitation to try to
implement it on my own.
I'd be a lot more inclined to do that (and able to) if I had
found pathname.lisp in the source instead of pathname.d.
I'm hoping that I can get someone else to do coding but let's
at least start with the spec.

First, does it make sense to leave logical pathnames alone and
just change physical pathnames?  I hope so.
In any case I'll just discuss physical pathnames below.

I propose what I think is the simplest possible change to the current
implementation to retain current functionality but distinguish between
literal strings and patterns.
I propose that components that can now be strings and also can be :wild
(this includes elements of directories) also be allowed to be lists 
containing strings and keywords.
The keywords initially supported are to be :wild and :wild1, 
representing the current interpretation of * and ?.
Parsing strings into pathnames will translate the strings 
representing such components containing * and ? into lists
such that 
(equal input-string
       (apply concatenate 'string 
              (substitute "*" :wild (substitute "?" :wild1 result))))
unless the component can be represented without such a list 
(either as a string containing no * or ? or as a single keyword)
Example:
 /asd?f/g*h?/*/zz =>
 (make-pathname
   :directory
   '(:absolute ("asd" :wild1 "f")("g" :wild "h" :wild1) :wild)
   :name "zz")
The functions that now create pathnames from actual file names
should not be creating wildcard patterns, so, for example, the 
directory function would translate a path like
 /asd?f/g*h?/*/zz
into 
 (make-pathname
   :directory
   '(:absolute "asd?f" "g*h?" "*")
   :name "zz")
which I think is what it does now.

However, wild-pathname-p would no longer return t for such a pathname.
It would return t only if the pathname contained one of the wildcard
keywords.
And as previously noted, printing pathnames with print-readably may 
(or may not) have to be changed.

Is that enough to entice someone else to implement it?  
What important details am I forgetting?