[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: PATHNAME-LOGICAL (version 2)
- To: Mlyemail@example.com
- Subject: Issue: PATHNAME-LOGICAL (version 2)
- From: "David A. Moon" <Moon@stony-brook.scrc.symbolics.com>
- Date: Thu, 25 May 89 13:12 EDT
- In-reply-to: <19890525163809.5.MLY@JACKIE-O.AI.MIT.EDU>
- Resent-comments: My comments on PATHNAME-LOGICAL (Version 2)
- Resent-date: Fri, 26 May 89 12:03 EDT
- Resent-from: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
- Resent-message-id: <19890526160304.1.MLY@ANNA-MAGDALENA-BACH.AI.MIT.EDU>
- Resent-to: CL-Cleanup@sail.stanford.edu
I might not agree with all of your points here, but I think they
are well-taken. Do you mind if I forward this message to
CL-Cleanup or do you want to keep it private?
Date: Thu, 25 May 89 12:38 EDT
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
1 I believe that mixing in the issue of parsing out host components from
pathname namestrings is a real mistake -- I hope it it grave enough to
kill this proposal (of the spirit of which I am otherwise extremely
To my thinking, a much better idea would be to define a new function, say,
(LOGICAL-PATHNAME <host-name> <namestring>) which would return a logical
This has the advantage of not requiring that CL get into the business
of deciding whether hosts in general are found by
"HOST:" or "HOST::" or "/../HOST/" or whatever, and I think that this is
necessary in order to avoid huge confusion.
It has the disadvantage of not -specifying- a way for users to type
a logical pathname on a specific when being prompted by the system
(ie it doesn't specify the format of the string one must feed into the
PATHNAME function in order to get out a specific logical pathname.
It should be noted that CLtL is silent in general on what strings
produce what results from PATHNAME and I suspect it would be a mistake
to attempt to change this at this stage -- my extremely positive
experiences with symbolics' integrated and largely-consistent pathname
Note that -implementations- are free to specify some way of specifying
logical pathnames -- Symbolics' specification would be that one
specifies a string with a prefix of "Logical-Host-Name:"
2 My second problem is with the syntax of the pathnames.
I really think that this pseudo-ITSism has gone on long enough.
It has pissed me off for years that bolix logical pathnames don't
have the same basic syntax as LMFS and FEP pathnames (which after all
have the best of all possible syntaxes. I'm not joking!)
I note the rationale
``The choice of logical pathname syntax was guided by the goal of being
visually distinct from real file systems.''
but have never bought this argument and never will. By the same reasoning,
shouldn't FEP filesystem pathnames be visually distinct from their LMFS
The present logical pathname syntax is just too complicated -- it's like
C code (do I have a use a #\; or a #\. here?) -- and more importantly,
makes it unnecessarily hard to express `the root directory' and
`up one directory level' and suchlike.
Another bug with the existing syntax is that it requires at least one level
of directory; this has often annoyed me with lispm logical directories.
One can't say "PCL:>*.*.*", one must instead use "PCL:>PCL>*.*.*" or somesuch.
DEFINE-LOGICAL-PATHNAME-TRANSLATIONS host translations &key [Function]
Define a logical pathname host named <host> (a string or a symbol which
is coerced to a string). <translations> is a list of translations.
Each translation is a list of from-wildcard and to-wildcard.
From-wildcard must be a logical pathname or a string coercible to a
logical pathname. To-wildcard must be a physical pathname or a string
coercible to a physical pathname. Translations are searched in the
order listed, so more specific from-wildcards must precede more general
3 Because of my point (1) above, I believe that the `left-hand' side of the
translation must be a string which is coerce to a logical pathname by the
[proposed] function (LOGICAL-PATHNAME <host-specified-by-first-arg-to-def-l-p-t> <the-string>)
There are problems with allowing `from-wildcard' to be a logical pathname object:
firstly, it is an error for it to be a logical pathname with a different logical
pathname host and secondly there are conceivable circularity problems with
actually defining or redefining such a form (the pathnames themselves depend
on the result of evaluating the whole form in some sense.)
So I'd require your examples to be written as
;A simple, and typical, example
;A more complex example
with the explicit proviso that the "MY-LISPM:" "MY-UNIX:" etc syntax on the
right-hand sides is implementation-specific