Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
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
(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)
'(:absolute ("asd" :wild1 "f")("g" :wild "h" :wild1) :wild)
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
'(:absolute "asd?f" "g*h?" "*")
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
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?