Pathnames are a powerful feature of Common Lisp, which often confuses
Common Lisp beginners. The following introductory paper is available
online:
Gene Michael Stover.
Pathnames quick-start & quick-reference.
The Lisp Magazine at lisp-p.org, September 2002.
http://www.lisp-p.org/htdocs/pathnames-0/
Paolo
--
Paolo Amoroso <·······@mclink.it>
Paolo Amoroso <·······@mclink.it> wrote in message news:<····························@4ax.com>...
> Pathnames are a powerful feature of Common Lisp, which often confuses
> Common Lisp beginners. The following introductory paper is available
> online:
>
> Gene Michael Stover.
> Pathnames quick-start & quick-reference.
> The Lisp Magazine at lisp-p.org, September 2002.
> http://www.lisp-p.org/htdocs/pathnames-0/
Thanks for the text! I found it a very good introduction, although I
have some constructive comments. First, even though logical pathnames
are supposed to be written in upper case letters, many implementations
manage both indistinctly. After
(setf (logical-pathname-translations "HOME") '(("**;*.*"
"/home/jlr/**/*.*")))
In CMUCL and ECL
> (translate-logical-pathname "HOME:MAILBOX")
#P"/home/jlr/MAILBOX"
> (translate-logical-pathname "HOME:MailBox")
#P"/home/jlr/MailBox"
> (translate-logical-pathname "HOME:mailbox")
#P"/home/jlr/mailbox"
while in CLISP
[27]> (translate-logical-pathname "HOME:MAILBOX")
#P"/home/jlr/mailbox."
[28]> (translate-logical-pathname "HOME:MailBox")
#P"/home/jlr/mailbox."
[29]> (translate-logical-pathname "HOME:mailbox")
#P"/home/jlr/mailbox."
Notice the different case and the final dot. I am not sure which
implementation is closer to the standard. In any case, I think it
would be nice to collect discrepancies like these for the most widely
used commercial and free implementations.
Also, in my wishes bag for _physical_ pathnames: a notation which
standarizes access to internet resources, via WWW, FTP, etc.
Finally, it would be nice to have these articles in PDF. I find it
more readable than plain HTML.
Juanjo
> * In message <··························@posting.google.com>
> * On the subject of "Re: Pathnames paper"
> * Sent on 31 Mar 2003 01:34:19 -0800
> * Honorable ····@arrakis.es (Juanjo) writes:
>
> (setf (logical-pathname-translations "HOME") '(("**;*.*"
> "/home/jlr/**/*.*")))
>
> In CMUCL and ECL
> > (translate-logical-pathname "HOME:MAILBOX")
> #P"/home/jlr/MAILBOX"
> > (translate-logical-pathname "HOME:MailBox")
> #P"/home/jlr/MailBox"
> > (translate-logical-pathname "HOME:mailbox")
> #P"/home/jlr/mailbox"
>
> while in CLISP
> [27]> (translate-logical-pathname "HOME:MAILBOX")
> #P"/home/jlr/mailbox."
> [28]> (translate-logical-pathname "HOME:MailBox")
> #P"/home/jlr/mailbox."
> [29]> (translate-logical-pathname "HOME:mailbox")
> #P"/home/jlr/mailbox."
>
> Notice the different case and the final dot. I am not sure which
> implementation is closer to the standard. In any case, I think it
> would be nice to collect discrepancies like these for the most widely
> used commercial and free implementations.
1. case: logical pathnames are case-insensitive, see
<http://www.lisp.org/HyperSpec/Body/sec_19-3-1.html>
19.3.1 Syntax of Logical Pathname Namestrings
i.e., "HOME:MAILBOX" and "HOME:mailbox" are identical logical
pathname strings (or, if you prefer, the latter is invalid because
the aforementioned page says "word---one or more uppercase letters,
digits, and hyphens.")
2. trailing dot: try
(setf (logical-pathname-translations "HOME")
'(("**;*" "/home/jlr/**/*")
("**;*.*" "/home/jlr/**/*.*")))
> Finally, it would be nice to have these articles in PDF. I find it
> more readable than plain HTML.
Funny - my view is the exact opposite (PDF is unreadable while HTML is nice)
--
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
"Complete Idiots Guide to Running LINUX Unleashed in a Nutshell for Dummies"
Sam Steingold <···@gnu.org> writes:
> 1. case: logical pathnames are case-insensitive, see
> <http://www.lisp.org/HyperSpec/Body/sec_19-3-1.html>
> 19.3.1 Syntax of Logical Pathname Namestrings
> i.e., "HOME:MAILBOX" and "HOME:mailbox" are identical logical
> pathname strings (or, if you prefer, the latter is invalid because
> the aforementioned page says "word---one or more uppercase letters,
> digits, and hyphens.")
I think it says "uppercase" pretty clearly. However, see also
19.3.1.1.7 Lowercase Letters in a Logical Pathname Namestring
When parsing words and wildcard-words, lowercase letters are
translated to uppercase.
I can't find anything in the spec that says what should happen to
lowercase components handed directly to MAKE-PATHNAME (i.e. that don't
go through PARSE-NAMESTRING). Personally (speaking as a user) I'd
like them to be upcased as well, but I don't know if that's justified
by the existing spec.
> Funny - my view is the exact opposite (PDF is unreadable while HTML is nice)
Likewise, actually
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
> I can't find anything in the spec that says what should happen to
> lowercase components handed directly to MAKE-PATHNAME (i.e. that don't
> go through PARSE-NAMESTRING). Personally (speaking as a user) I'd
> like them to be upcased as well, but I don't know if that's justified
> by the existing spec.
The pathname chapter is one of the worst in the spec. We ran out of
time/budget while I was just getting into cleaining it up. Your guess
is as good as anyone's.
I think it's reasonable to hope it will get case-translated in
MAKE-PATHNAME [it's what I'd personally prefer] but it's possible it
doesn't happen in some implementations until there is a translation
done. That is, MAKE-PATHNAME might just quietly accept lowercase and
maintain it as is.
> > Funny - my view is the exact opposite (PDF is unreadable
> > while HTML is nice)
>
> Likewise, actually
I like sometimes one and sometimes the other. I'd like PDF a lot more
if I didn't feel the drag of Internet Explorer launching a separate
program and changing my interface (not just navigation, but what kinds
of things I can click on and how they light up), and that probably
biases me such that I'm not expressing a preference for presentation
as much as for a particular browser.
Kent M Pitman wrote:
> Daniel Barlow <···@telent.net> writes:
>
>>I can't find anything in the spec that says what should happen to
>>lowercase components handed directly to MAKE-PATHNAME (i.e. that don't
>>go through PARSE-NAMESTRING). Personally (speaking as a user) I'd
>>like them to be upcased as well, but I don't know if that's justified
>>by the existing spec.
>
> The pathname chapter is one of the worst in the spec. We ran out of
> time/budget while I was just getting into cleaining it up. Your guess
> is as good as anyone's.
>
> I think it's reasonable to hope it will get case-translated in
> MAKE-PATHNAME [it's what I'd personally prefer] but it's possible it
> doesn't happen in some implementations until there is a translation
> done. That is, MAKE-PATHNAME might just quietly accept lowercase and
> maintain it as is.
It is no less reasonable to hope that the pathname words will get Godel
encoded as radix 7 numbers, but there is no more or less justification
in the ANS for one than the other.
It isn't that the pathname chapter of the ANS is poorly written. The
real problem is that the pathname system design was poorly thought out
and there was little experience with actual implementations of the
thing we approved. Something similar existed on Lisp Machines, but
LMs were already becoming unimportant in market share, and the way
the pathname system operates with other common OS filesystems leaves
much to be desired, IMO.
For example, _real_ systems may contain files that are not Lisp files.
While all Lisp implementation files can be named with single-case
filenames, as suggested by the ANS, some existing non-Lisp files
have mixed-case names, and those names are defined by other languages.
While there is no moral necessity that the CL ANS provide for these,
it would make the system-construction tool potential of CL more
powerful if it could handle these naturally.
The late binding of logical pathnames if, of course, a brilliant
feature in a language. But it would have been nice if we got the
details rather more lispy, and also understandable by human
intelligence. The nice design feature of pathname calculus is
that it moved most of the details about lp translation into the
domain of implementation-defined dorking of the lp-translation
triples (he l-p, the from-widlcard, and the to-wildcard). The bad
thing about that design is that it didn't provide for reflection or
application-code extension of the translation mechanics.
The lisp world would have been a nicer place if l-p-translation
were a from-wildcard and a function (or list of functions) of two
arguments, the wildcard and the argument pathname. Since the
pathname calculus is otherwise well defined, allowing the
translator specifications to be embodied by functions allows the
application to extend it. Having the translations be a list of
functions provides for encapsulation. Details left as an exercise
for the language designer.
Something like this would have been a traditional, lispy API for
an ugly OS-dependent problem. We missed it 11-12 years ago. If
we hadn't missed it, the case of translated pathnames would not
have been an issue.
"Steven M. Haflich" <·················@alum.mit.edu> writes:
> The lisp world would have been a nicer place if l-p-translation
> were a from-wildcard and a function (or list of functions) of two
> arguments, the wildcard and the argument pathname. Since the
> pathname calculus is otherwise well defined, allowing the
> translator specifications to be embodied by functions allows the
> application to extend it. Having the translations be a list of
> functions provides for encapsulation. Details left as an exercise
> for the language designer.
Not a terribly bad idea, really, except it would require two
functions, since one reason that the things are as they are is to
allow the lispm functionality "back-translated-pathname" to reverse
the wildcard translation given the same pair of from and two
pathnames. (I think it's not a perfect process, since I think
the reverse mapping is technically one to many and so just picks
one of the choices, but it's good enough for some uses.) Having two
functions would actually give you more reliable control of
backtranslation, too, though.
> Something like this would have been a traditional, lispy API for
> an ugly OS-dependent problem. We missed it 11-12 years ago. If
> we hadn't missed it, the case of translated pathnames would not
> have been an issue.
Probably.
Then again, the LispM system was well-thought-out, and the reason we
didn't use it, IMO (since it's always a matter of opinion why someone
didn't vote for something, and sometimes even why they did) was that
the committee shied away from taking all of anything the LispM did for
fear of becoming bloated. (A laughable concern to those from the
Scheme community, perhaps, who think we did that _anyway_.) The
tendancy of the committee was to take half or 2/3 of the LispM
approach and assume they were being prudent. But the LispM system was
rock-solid tested on a large number of operating systems in real use
for a decade by the time the feature freeze happened, and it would have
been wiser, I think, to take more of its solution than to assume that
taking pieces of it weren't good.
You mentioned reflection. Certainly the LispM system did allow for
more of that, for example... But then, the LispM was little else.
Everyone knew how most everything was implemented, and patches to
system code were common where there was a deficiency. (That didn't
make it "free software", for those looking on who aren't familiar. It
just was software that was "open" under a "trade secret" license, so
that customers could read and patch the code but not give it away to
competitors. At least that's how the Symbolics system worked. I
can't speak to how the LMI/MIT/TI [aka LMITI] system worked at the
legal level.)
On 31 Mar 2003 01:34:19 -0800, ····@arrakis.es (Juanjo) wrote:
> Paolo Amoroso <·······@mclink.it> wrote in message news:<····························@4ax.com>...
[...]
> > Gene Michael Stover.
> > Pathnames quick-start & quick-reference.
> > The Lisp Magazine at lisp-p.org, September 2002.
> > http://www.lisp-p.org/htdocs/pathnames-0/
>
> Thanks for the text! I found it a very good introduction, although I
> have some constructive comments. First, even though logical pathnames
[...]
I suggest that you also forward your comments to the author, because I'm
not sure he's following this thread.
Paolo
--
Paolo Amoroso <·······@mclink.it>