(CLtS question) Pathname hosts
Paul F. Dietz
a 'valid pathname host'. In the glossary, this type is defined to be a string,
a list of strings, the symbol :unspecific, or a string that is a logical pathname
host.
However, section 19.2.2.4.1 says 'It is implementation-dependent what object is
used to represent the host.' I take this to mean that PATHNAME-HOST may return
one of these implementation-dependent values.
What was intended here?
Paul
Kent M Pitman
One of these implementation-dependent values? Heh...
Or not.
Hmm, lemme try again.
Intended? Hahahahahahahaha....
You, of course, meant to ask what was "voted".
Committees operate by vote and this, if ever there was, is one of those
committee decisions they warn you about.
Hmm, lemme try again...
In the Symbolics implementation, it returned a file host object, and IMO
that works best so I personally wouldn't want to exclude it.
X3J13 kept adopting 1/2 (or some other fraction) of what Symbolics did and
calling that "conservative". Sometimes it was just "incomplete design".
I cleaned some of it up editorially, but some of it required a vote to fix
and we didn't get that far. The pathnames section was the worst in the spec
not because it was so badly designed at the lowest level, but because there
were so many details left vague. And we just had to stop and get the
standard out. So I apologize for leaving it hanging, and yet I also accept
that sometimes budgetary considerations come into play. It was next on my
list to fix up when we stopped for release.
I think just assuming it's an implementation-dependent object is good
and safe and reasonable.
I think it's reasonable to assume it's non-null, if that helps.
(Explaining why that is so is kind of a "derived fact" -- it's probably
not mentioned directly anywhere.)
Incidentally, a common question is what a list of strings is about, and
to answer that you'd have to go back to the vax notion of naming files by
allowing
FOO::BAR::BAZ::X
where FOO, BAR, and BAZ are hosts.
Christophe Rhodes
> [pathname host]
>
> I think it's reasonable to assume it's non-null, if that helps.
> (Explaining why that is so is kind of a "derived fact" -- it's probably
> not mentioned directly anywhere.)
Just to throw more oil on the troubled waters, note that the null
object NIL is a (degenerate) list of strings, and so is explicitly
permitted by at least one reading of the standard. :-)
Christophe "running for cover now"
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Kent M Pitman
> Kent M Pitman <pit...@nhplace.com> writes:
>
> > [pathname host]
> >
> > I think it's reasonable to assume it's non-null, if that helps.
> > (Explaining why that is so is kind of a "derived fact" -- it's probably
> > not mentioned directly anywhere.)
>
> Just to throw more oil on the troubled waters, note that the null
> object NIL is a (degenerate) list of strings, and so is explicitly
> permitted by at least one reading of the standard. :-)
That's why I said it's a derived truth. The datatype permits it but
what doesn't permit it is that NIL is defined to mean "unfilled" and
you were able to use NIL in some single-file-system implementations as
the default host under CLTL because there might be only one file host,
and because there was no difference in such cases between filled and
unfilled. But once we introduced logical hosts, all implementations are,
by definition, multi-file-host, and as such, it matters whether the host
is filled or not. And as such, NIL cannot be used to mean filled without
merging rules being broken. So the value cannot be NIL.
Joe Marshall
I agree. Unfortunately, several implementations think that NIL is the
canonical name for localhost.
--
~jrm
Pascal Bourguignon
> "Paul F. Dietz" <di...@dls.net> writes:
>
> > On the page for the PATHNAME-HOST function, the function is defined
> > as returning a 'valid pathname host'. In the glossary, this type is
> > defined to be a string, a list of strings, the symbol :unspecific,
> > or a string that is a logical pathname host.
> >
> > However, section 19.2.2.4.1 says 'It is implementation-dependent
> > what object is used to represent the host.' I take this to mean
> > that PATHNAME-HOST may return one of these implementation-dependent
> > values.
> >
> > What was intended here?
> [...]
> I think it's reasonable to assume it's non-null, if that helps.
> (Explaining why that is so is kind of a "derived fact" -- it's probably
> not mentioned directly anywhere.)
[2]> (pathname-host #"/tmp")
NIL
--
__Pascal_Bourguignon__ . * * . * .* .
http://www.informatimago.com/ . * . .*
* . . /\ () . *
Living free in Alaska or in Siberia, a . . / .\ . * .
grizzli's life expectancy is 35 years, .*. / * \ . .
but no more than 8 years in captivity. . /* o \ .
http://www.theadvocates.org/ * '''||''' .
SCO Spam-magnet: postm...@sco.com ******************
Kent M Pitman
Then they are in violation of the specification's restrictions on merging.
All pathnames have host merged in. That's a requirement.
It is further a requirement that merging does not disturb a filled field.
So they don't have to believe me that NIL is not a possible value for host;
they can just play with the puzzle themselves until they have a way to
satisfy those two constraints. But I bet when they're done, NIL will not
be a possible host value. ;)
Kent M Pitman
> Kent M Pitman <pit...@nhplace.com> writes:
>
> > "Paul F. Dietz" <di...@dls.net> writes:
> >
> > > On the page for the PATHNAME-HOST function, the function is defined
> > > as returning a 'valid pathname host'. In the glossary, this type is
> > > defined to be a string, a list of strings, the symbol :unspecific,
> > > or a string that is a logical pathname host.
> > >
> > > However, section 19.2.2.4.1 says 'It is implementation-dependent
> > > what object is used to represent the host.' I take this to mean
> > > that PATHNAME-HOST may return one of these implementation-dependent
> > > values.
> > >
> > > What was intended here?
> > [...]
> > I think it's reasonable to assume it's non-null, if that helps.
> > (Explaining why that is so is kind of a "derived fact" -- it's probably
> > not mentioned directly anywhere.)
>
> [2]> (pathname-host #"/tmp")
> NIL
I assume you mean #P"/tmp" here.
I don't think you have any reason to suppose this result to be either
definitive nor even conforming.
I have always assumed that pathname-host does make-pathname on the
local host. If it does not have a host against which to parse, it
can't know if / is a directory marker, an ordinary alphabetic or, for
that matter, a file host identifier.... There has to be a default
host in order for name parsing to succeed.
And if there is, it has to be not NIL because otherwise merging would
not hold onto it. That is,
(pathname-host (merge-pathnames #P"/tmp" "SYS:FOO;X.LISP"))
should return
#P"MY-DEFAULT-HOST:/tmp/x.lisp"
if MY-DEFAULT-HOST is a Unix and
#P"MY-DEFAULT-HOST:foo:/tmp"
if MY-DEFAULT-HOST is a Macintosh (since / is an alphabetic there).
But it should not return
#P"FOO:/tmp"
nor
#P"/tmp/x.lisp"
because this presupposes (falsely) that no file system semantics have
been used yet, which plainly they have at the time of the PARSE-NAMESTRING
in the #P reference.
Even just
(DESCRIBE #P"/tmp")
should show either
HOST: #<MACINTOSH-HOST "MY-DEFAULT-HOST">
DEVICE: :UNSPECIFIC
DIRECTORY: NIL
NAME "/TMP"
TYPE NIL
VERSION NIL
on a Mac and
HOST: #<UNIX-HOST "MY-DEFAULT-HOST">
DEVICE: :UNSPECIFIC
DIRECTORY: (:ABSOLUTE "TMP")
NAME NIL
TYPE NIL
VERSION NIL
for Unix.
because already you've used the host info.
Just putting NIL there invites a later confusion.
Joe Marshall
Well let's see.
Starting an `out of the box' lisp with no init file:
Allegro CL:
(describe (user-homedir-pathname))
#p"c:\\" is a structure of type PATHNAME. It has these slots:
HOST NIL
DEVICE "c"
DIRECTORY (:ABSOLUTE)
NAME NIL
TYPE NIL
VERSION :UNSPECIFIC
NAMESTRING "c:\\"
HASH NIL
DIR-NAMESTRING "\\"
(make-pathname :host "localhost")
Lispworks:
(describe (user-homedir-pathname))
#P"C:/Home/Jrm/" is a PATHNAME
HOST "C"
DEVICE NIL
DIRECTORY (:ABSOLUTE "Home" "Jrm")
NAME NIL
TYPE NIL
VERSION NIL
CLisp:
(describe (user-homedir-pathname))
#P"C:\\Home\\Jrm\\" is a pathname, with the following components:
DEVICE = C:
DIRECTORY = \Home\Jrm\
The Lispworks one is weird, but I guess defensible. Personally,
though, I consider the various drives on my machine to be devices
rather than hosts. Since most other lisps concur, it makes it a pain
to write portable code.
--
~jrm
Pascal Bourguignon
> Pascal Bourguignon <sp...@thalassa.informatimago.com> writes:
>
> > Kent M Pitman <pit...@nhplace.com> writes:
> >
> > > "Paul F. Dietz" <di...@dls.net> writes:
> > >
> > > > On the page for the PATHNAME-HOST function, the function is defined
> > > > as returning a 'valid pathname host'. In the glossary, this type is
> > > > defined to be a string, a list of strings, the symbol :unspecific,
> > > > or a string that is a logical pathname host.
> > > >
> > > > However, section 19.2.2.4.1 says 'It is implementation-dependent
> > > > what object is used to represent the host.' I take this to mean
> > > > that PATHNAME-HOST may return one of these implementation-dependent
> > > > values.
> > > >
> > > > What was intended here?
> > > [...]
> > > I think it's reasonable to assume it's non-null, if that helps.
> > > (Explaining why that is so is kind of a "derived fact" -- it's probably
> > > not mentioned directly anywhere.)
> >
> > [2]> (pathname-host #"/tmp")
> > NIL
>
> I assume you mean #P"/tmp" here.
I did. But clisp takes both as pathnames:
[10]> (type-of #"/tmp")
PATHNAME
[11]> (type-of #P"/tmp")
PATHNAME
> I don't think you have any reason to suppose this result to be either
> definitive nor even conforming.
Just to note that in practice some implementations that strive to be
conforming still return NIL. I don't think we can blame implementors
for such errors.
> I have always assumed that pathname-host does make-pathname on the
> local host. If it does not have a host against which to parse, it
> can't know if / is a directory marker, an ordinary alphabetic or, for
> that matter, a file host identifier.... There has to be a default
> host in order for name parsing to succeed.
>
> And if there is, it has to be not NIL because otherwise merging would
> not hold onto it. That is,
>
> (pathname-host (merge-pathnames #P"/tmp" "SYS:FOO;X.LISP"))
>
> should return
>
> #P"MY-DEFAULT-HOST:/tmp/x.lisp"
>
> if MY-DEFAULT-HOST is a Unix and
>
> #P"MY-DEFAULT-HOST:foo:/tmp"
>
> if MY-DEFAULT-HOST is a Macintosh (since / is an alphabetic there).
> But it should not return
>
> #P"FOO:/tmp"
>
> nor
>
> #P"/tmp/x.lisp"
>
> because this presupposes (falsely) that no file system semantics have
> been used yet, which plainly they have at the time of the PARSE-NAMESTRING
> in the #P reference.
[9]> (merge-pathnames #P"/tmp" "SYS:FOO;X.LISP")
#S(LOGICAL-PATHNAME :HOST "SYS" :DEVICE NIL :DIRECTORY (:ABSOLUTE) :NAME "tmp"
:TYPE "LISP" :VERSION :NEWEST)
[10]> (pathname-host (merge-pathnames #P"/tmp" "SYS:FOO;X.LISP"))
"SYS"
Perhaps you meant:
[12]> (namestring (merge-pathnames #P"/tmp" "SYS:FOO;X.LISP"))
"SYS:tmp.LISP.0"
Perhaps the standard did not specify enough...
> Even just
>
> (DESCRIBE #P"/tmp")
>
> should show either
>
> HOST: #<MACINTOSH-HOST "MY-DEFAULT-HOST">
> DEVICE: :UNSPECIFIC
> DIRECTORY: NIL
> NAME "/TMP"
> TYPE NIL
> VERSION NIL
>
> on a Mac and
>
> HOST: #<UNIX-HOST "MY-DEFAULT-HOST">
> DEVICE: :UNSPECIFIC
> DIRECTORY: (:ABSOLUTE "TMP")
> NAME NIL
> TYPE NIL
> VERSION NIL
>
> for Unix.
>
> because already you've used the host info.
>
> Just putting NIL there invites a later confusion.
--
Kent M Pitman
> The Lispworks one is weird, but I guess defensible. Personally,
> though, I consider the various drives on my machine to be devices
> rather than hosts. Since most other lisps concur, it makes it a pain
> to write portable code.
In a perfect world, I would, too. But fortunately or unfortunately,
there are several operating systems (LispM, Windows, and Linux to name
three, and probably others I don't think of on spur of moment) that
have file structures with differing capabilities. LispWorks and
Symbolics, at least, prefer to refer to "file hosts" (distinguished
from "network hosts") to resolve this issue. FEPFS (the front end
processor's file system) is an example in the Lisp Machine where this
happens. Drives C and D being FAT vs NTFS on a Windows machine is
another example. These being different "file hosts" is useful because
the numbers of characters allowed in the file system, the kinds of
operations allowed, the kinds of properties maintained, the space of
permissions, and other things might vary. Calling these all "the same
host" doesn't give you much to dispatch off. Two processors with
different operating systems might both have the same kind of file
system accessible, and, in fact, it might be the same physical disk.
So I think their choice is quite defensible.
Christophe Rhodes
> Kent M Pitman <pit...@nhplace.com> writes:
>
>> I don't think you have any reason to suppose this result to be either
>> definitive nor even conforming.
>
> Just to note that in practice some implementations that strive to be
> conforming still return NIL. I don't think we can blame implementors
> for such errors.
The default startup mode for clisp is explicitly non-conforming in
several aspects. While the rhetoric in the manual page has been toned
down in recent years, it remains the case that there are differences
in behaviour between those specified and those implemented. And, to
the extent that these are conscious choices rather than just bugs (and
to the extent that the pathname specification is self-consistent...)
yes of course we can blame, or praise, implementors for the choices
they make.
Christophe
Marco Antoniotti
Kent M Pitman wrote:
Well, Mac OS X is pretty much a Unix now (isn't it? :) )
>
> on a Mac and
>
> HOST: #<UNIX-HOST "MY-DEFAULT-HOST">
> DEVICE: :UNSPECIFIC
> DIRECTORY: (:ABSOLUTE "TMP")
> NAME NIL
> TYPE NIL
> VERSION NIL
>
> for Unix.
>
> because already you've used the host info.
This would make PARSE-NAMESTRING dependent on the state of the
underlying file system, wouldn't it? I always thought that
PARSE-NAMESTRING should be definable independently of the state of the
underlying file system. How can you reliably ask PARSE-NAMESTRING to
figure out, on a UNIX host, that "/tmp" refers to a directory and not to
a file without checking the state of the underlying file system?
>
> Just putting NIL there invites a later confusion.
Yes. On that I definitively agree.
Cheers
--
Marco
Pascal Bourguignon
Marco Antoniotti <mar...@cs.nyu.edu> writes:
> Well, Mac OS X is pretty much a Unix now (isn't it? :) )
And just to make things more interesting, on MacOSX, when accessing
files on HFS, as on UFS or NFS, we use unix syntax, not MacOS syntax.
So I'm not sure the rational given by Kent is really pertinent.
Is there really a system where paths have different syntax depending
on where they point to?
Kent M Pitman
> This would make PARSE-NAMESTRING dependent on the state of the
> underlying file system, wouldn't it? I always thought that
> PARSE-NAMESTRING should be definable independently of the state of the
> underlying file system.
The Lisp Machine, faced with this issue, used a convention called the
'host colon convention' for making the state independent of the host
machine (other than *default-pathname-defaults*). What it said was
that the first colon in a namestring would definitively terminate a
host and all parsing would be with respect to that host; otherwise,
all parsing was with respect to the host in *default-pathname-defaults*.
When you wanted to say
D:\foo
on some default PC, you'd write :D:\\foo to take the default file system.
The first : said "take the default host" (which is what "" represented).
If you wanted to name a specific machine, you wrote "FOO:D:\\foo".
Of course, an implication of the "host colon" convention is that the
namestring of a pathname could never be appropriate to give to a host,
since the host would not be expecting a host name (except VAX VMS, which
we'll ignore for simplicity as anomalous; in general, you can't make all
file systems do that because--well,--because they already don't and they
aren't likely to change on our account).
[Aside: Someone at Symbolics (I know who but am not sure he'd want his
name in lights on this) used to suggest that we make up a new
character which looked like a chalice and call it the 'host' character
and use it as a separator instead of colon so that the separator
didn't interfere with native operating system characters.
Probably-thankfully, we didn't. (I suppose if we had, it would have
gotten onto the 'giant colon' key on a lispm keyboard, and soon people
would have wanted keywords to start with chalices, and the whole thing
would have been a disaster. We did have SOME restraint in lispm
design, thank goodness.)]
Anyway, the CL committee did not like the host colon convention, I believe
(but am not sure I either ever understood nor that I remember right) because
it was overcomplicated and because it meant having yet another operator
(which I claim you need now anyway, so it was a false economy) to yield
the STRING-FOR-HOST of the pathname. (Then again, STRING-FOR-HOST would
have invited questions about what a host was, and then we'd have had to
define more of that, and ... pretty soon the pathname system would have
looked as complete as the lispm file system, and ... ok, ok, I'll try not
to sound too bitter about how I think in this case "gratuitous
conservativism" plus a healthy does of NIH led to what I think was
bad design (really mostly just "incomplete design", with not even a hint
of guidance for the future, in the way that MOP filled gaps in CLOS).
> How can you reliably ask PARSE-NAMESTRING to
> figure out, on a UNIX host, that "/tmp" refers to a directory and not
> to a file without checking the state of the underlying file system?
On the LispM, and again I suppose this is baggage no one wanted (but
it's not like you can pretend it's not something programs have to
represent, since it's real and it affects things), you can ask of a
file host what kind of file host it is. And there are tools for
maintaining that kind of 'database' about hosts. And fallbacks to weaker
sets of operations on hosts that haven't been declared and are assumed to
be of type "random host".
Kent M Pitman
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
> > Well, Mac OS X is pretty much a Unix now (isn't it? :) )
>
> And just to make things more interesting, on MacOSX, when accessing
> files on HFS, as on UFS or NFS, we use unix syntax, not MacOS syntax.
>
> So I'm not sure the rational given by Kent is really pertinent.
>
> Is there really a system where paths have different syntax depending
> on where they point to?
The Lisp Machine, certainly. Its native file system uses '>' for directory
portion end-markers and '<' for :UP.
The logical pathname system. It uses ';'.
Any future Lisp like the Lisp Machine (or certain Sun machines and
probably others) that wants to exist on the net, perhaps even
diskless, and to only use whatever file system it happens to be asked to.
It's very short-sighted to be doing the thing you're doing of saying
"couldn't we just imagine the world will be always constrained" or even
"is approaching convergence".
The ISO 9nnn (can't remember the number) file system is also different,
as I recall, so anyone who wants to address those things directly without
having it re-worked through some native OS sugar has an issue, too.
Thomas A. Russ
MCL returns :UNSPECIFIC
--
Thomas A. Russ, USC/Information Sciences Institute
james anderson
Pascal Bourguignon wrote:
>
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
> > Well, Mac OS X is pretty much a Unix now (isn't it? :) )
>
> And just to make things more interesting, on MacOSX, when accessing
> files on HFS, as on UFS or NFS, we use unix syntax, not MacOS syntax.
was that a royal we? or am i missing something?
...
Pascal Bourguignon
I was asking whether there was OS (or implementation of Common-Lisp)
where you'd have to write:
cp macos-host:Macintosh\ HD:Personal\ Folder:My\ File \
unix-host:/home/pascal/my-file
(or:
(copy-file "MACOSHOST:MACINTOSH-HD;PERSONAL-FOLDER;MY-FILE"
"UNIXHOST:HOME;PASCAL;MY-FILE")
oops, I meant:
(copy-file #P"MACOSHOST:Macintosh HD:Personal Folder:My File"
#P"UNIXHOST:/home/pascal/my-file")
)
Pascal Bourguignon
No.
bash-2.05a$ uname
Darwin
bash-2.05a$ /bin/ls /Users/pascal/thalassa/src/lisp
doc fare norvig
emacs-tidbits libapache-mod-lisp-2.2 sursis
encours loaders
bash-2.05a$ df -T
Filesystem Type 1k-blocks Used Available Use% Mounted on
/dev/disk0s5 hfs 58599900 28213328 30130572 49% /
thalassa.informatimago.com:/data
nfs 29036564 26120152 2916412 90% /thalassa/data
/Users/pascal is on a HFS+ volume; /Users/pascal/thalassa is on a
reiserfs volume mounted via NFS.
If I've understood what was being said, we would have had to write:
naiad:Macintosh\ HD:bin:ls naiad:Macintosh\ HD:Users:pascal:thalassa/src/lisp
Or some silly thing like that.
Note that logical pathnames specify only ONE syntax, whatever the
logical host is. MacOSX is unix so we only use unix syntax to name
stuff whatever the host on which this stuff lies.
Another example would be ftp or scp.
Christopher C. Stacy
Pascal> I was asking whether there was OS (or implementation of Common-Lisp)
Pascal> where you'd have to write:
Pascal> (copy-file #P"MACOSHOST:Macintosh HD:Personal Folder:My File"
Pascal> #P"UNIXHOST:/home/pascal/my-file")
That's what you would do on the Lisp Machine.
I might be missing the point of your message, though.
Your wording "have to write" suggests that you don't
think this is the wonderful feature that some people
consider it to be. Why is that?
james anderson
i had understood the discussion to pertain to pathname designators in lisp,
not in a unix shell.
Pascal Bourguignon wrote:
>
>
> If I've understood what was being said, we would have had to write:
>
> naiad:Macintosh\ HD:bin:ls naiad:Macintosh\ HD:Users:pascal:thalassa/src/lisp
>
> Or some silly thing like that.
>
you might want to take a look at mcl. people have been using it to do silly
things for about twenty years now.
...
Pascal Bourguignon
> i had understood the discussion to pertain to pathname designators in lisp,
> not in a unix shell.
Physical pathnames in lisp are the same as used in a unix shell, when
the lisp implementation is on unix. At least, it should.
> Pascal Bourguignon wrote:
> >
> >
> > If I've understood what was being said, we would have had to write:
> >
> > naiad:Macintosh\ HD:bin:ls naiad:Macintosh\ HD:Users:pascal:thalassa/src/lisp
> >
> > Or some silly thing like that.
> >
>
> you might want to take a look at mcl. people have been using it to do silly
> things for about twenty years now.
>
> ...
--
Christophe Rhodes
> james anderson <james.a...@setf.de> writes:
>
>> i had understood the discussion to pertain to pathname designators in lisp,
>> not in a unix shell.
>
> Physical pathnames in lisp are the same as used in a unix shell, when
> the lisp implementation is on unix. At least, it should.
There is a very strong argument for Lisp implementations on Unix to
prepend a colon to the Unix pathname to generate the Lisp namestring.
At least, there would be if current Lisp implementations on Unix
actually did anything interesting at all with the host field.
On the other hand, since the Common Lisp pathname system goes out of
its way to prevent using Unix pathnames -- not to mention URIs -- as
pathnames, it's not clear what can be gained in discussing the
semantics of Lisp pathnames on Unix besides a rather stong headache.
james anderson
Pascal Bourguignon wrote:
>
> james anderson <james.a...@setf.de> writes:
>
> > i had understood the discussion to pertain to pathname designators in lisp,
> > not in a unix shell.
>
> Physical pathnames in lisp are the same as used in a unix shell, when
> the lisp implementation is on unix. At least, it should.
when i am concerned about portability, i try to remain aware that, with the
exception of logical pathname nemestrings, "[i]n general, the syntax of
namestrings involves the use of implementation-defined conventions, usually
those customary for the file system in which the named file resides."
according to which, "implementation dependent" is twice removed, that is, both
by custom and by uncertainty, from a necessary identity with any given file
system syntax. not to mention, that, where the underlying os goes to some
lengths to support universal resource locators as generic stream designators,
and provides means for them to subsume posix-syntax file designators, the
syntax which is customary in the underlying os, is not necessarily that which
is customary in the usual unix shells.
i suspect also that, given the compatibility issues, the mcl implementors made
the correct decision, to avail themselves of the latitude which that
specification permits, and to allow that, at least for an interim period, the
"implementation-defined" notation for physical pathnames remain close to that
which was customary under os9.
>
> > Pascal Bourguignon wrote:
> > >
> > >
> > > If I've understood what was being said, we would have had to write:
> > >
> > > naiad:Macintosh\ HD:bin:ls naiad:Macintosh\ HD:Users:pascal:thalassa/src/lisp
> > >
> > > Or some silly thing like that.
> > >
> >
> > you might want to take a look at mcl. people have been using it to do silly
> > things for about twenty years now.
> >
> > ...
...
Pascal Bourguignon
> Pascal Bourguignon <sp...@thalassa.informatimago.com> writes:
>
> > james anderson <james.a...@setf.de> writes:
> >
> >> i had understood the discussion to pertain to pathname designators in lisp,
> >> not in a unix shell.
> >
> > Physical pathnames in lisp are the same as used in a unix shell, when
> > the lisp implementation is on unix. At least, it should.
>
> There is a very strong argument for Lisp implementations on Unix to
> prepend a colon to the Unix pathname to generate the Lisp namestring.
> At least, there would be if current Lisp implementations on Unix
> actually did anything interesting at all with the host field.
>
> On the other hand, since the Common Lisp pathname system goes out of
> its way to prevent using Unix pathnames -- not to mention URIs -- as
> pathnames, it's not clear what can be gained in discussing the
> semantics of Lisp pathnames on Unix besides a rather stong headache.
Agreed. In my opinion, this area needs much work for a next release
of the standard.
Marco Antoniotti
What you write is very interesting. However, what should
(setf foo (PARSE-NAMESTRING "/tmp"))
on a UNIX host return?
Should
(PATHANME-DIRECTORY foo) ==> (:ABSOLUTE)
or
(PATHNAME-DIRECTORY foo) ==> (:ABSOLUTE "tmp")
?
Of course, all of this maintaining the "PARSE-NAMESTRING must not
consult the File System to make the decision" mantra.
The question is important. This is one of those "implementation
dependent" details that should be removed from the language.
Cheers
--
Marco
Kent M Pitman
Hey, I was going to write that!!
Indeed, my only problem with the question is the "have to" rather than
"get to". People who have used this have loved it. It was SO much more
simple to have connectivity to the entire then-Arpanet/now-Internet worked
into the basic functions of Lisp rather than having to write elaborate
programs....
And, of course, you rarely wrote it as constant strings. More often
you wrote it as [I'm simplifying the syntax for this situation]:
(define-command-processor-command "Copy File" ((from-file pathname)
(to-file pathname))
(copy-file from-file to-file))
and then you let someone issue a command like:
Command: Copy File (from file [default HOST:FRED:MY.LETTER]) "MACOSHOST:FRED:My Files:my-favorite-file" (to file) UNIXHOST:/home/sam/freds-favorite-file
The nice thing was taht the definition of the command processor never
had to mention it was doing network I/O at all, yet it would do it if
asked. If you wanted to do something that only copied in the local
file system and made it hard to be general, you could do that. But no
one much did, as far as I know.
Marco Antoniotti
Christophe Rhodes wrote:
> Pascal Bourguignon <sp...@thalassa.informatimago.com> writes:
>
>
>>james anderson <james.a...@setf.de> writes:
>>
>>
>>>i had understood the discussion to pertain to pathname designators in lisp,
>>>not in a unix shell.
>>
>>Physical pathnames in lisp are the same as used in a unix shell, when
>>the lisp implementation is on unix. At least, it should.
>
>
> There is a very strong argument for Lisp implementations on Unix to
> prepend a colon to the Unix pathname to generate the Lisp namestring.
Why should it be like this?
> At least, there would be if current Lisp implementations on Unix
> actually did anything interesting at all with the host field.
This does not apply solely to UNIX. Since these days I am working
mostly on Windows, I'd say that the same argument applies to other OSes
as well. The truth is that a "new" spec should address essentially the
Windows and the UNIX filesystems (given that Mac OS 9 pathnames are
bound to disappear,) plus UR{NIL} (with the proviso that networking
issues have to be trated in a separate way.)
> On the other hand, since the Common Lisp pathname system goes out of
> its way to prevent using Unix pathnames -- not to mention URIs -- as
> pathnames, it's not clear what can be gained in discussing the
> semantics of Lisp pathnames on Unix besides a rather stong headache.
I agree with this. However, in all fairness, UR{NIL} stuff was not
known at the time of the writing of the ANSI spec.
Cheers
--
Marco
Pascal Bourguignon
> cst...@news.dtpq.com (Christopher C. Stacy) writes:
>
> > >>>>> On 09 Dec 2003 09:02:20 +0100, Pascal Bourguignon ("Pascal") writes:
> >
> > Pascal> I was asking whether there was OS (or implementation of Common-Lisp)
> > Pascal> where you'd have to write:
> >
> > Pascal> (copy-file #P"MACOSHOST:Macintosh HD:Personal Folder:My File"
> > Pascal> #P"UNIXHOST:/home/pascal/my-file")
> >
> > That's what you would do on the Lisp Machine.
That sounds crazy to me.
The Lisp Machine OS was not able to provide the user a single syntax
to navigate file systems? How would the user be able to browse any
alien file system then?
I'm happy to be able to mount NFS from MacOS servers, from MS-Windows
servers, or Samba file systems from Linux or MS-WIndows servers, and
in ALL cases, access the imported volumes with the same unix
syntax. Come to think of it, the unix path syntax is like the logical
path syntax: a uniformizing one.
It just happens that MacOS did the same thing and uniformized all
paths to MacOS paths. And MSDOS did the same thing once again and
uniformized all paths to MS-DOS paths. When I mounted SCO unix file
systems thru NFS on MS-Windows 3.11, I accessed unix files with MS-DOS
paths: "E:\USR\LOCAL\SRC\PROJECT1\FILE.C".
I can't imagine what path you would have to write when accessing thru
one NFS server volumes mounted on that NFS server from another server
with a different again kind of file system and path syntax.
--
__Pascal_Bourguignon__ . * * . * .* .
http://www.informatimago.com/ . * . .*
There is no worse tyranny than to force * . . /\ () . *
a man to pay for what he does not . . / .\ . * .
want merely because you think it .*. / * \ . .
would be good for him. -- Robert Heinlein . /* o \ .
Joe Marshall
> It just happens that MacOS did the same thing and uniformized all
> paths to MacOS paths. And MSDOS did the same thing once again and
> uniformized all paths to MS-DOS paths. When I mounted SCO unix file
> systems thru NFS on MS-Windows 3.11, I accessed unix files with MS-DOS
> paths: "E:\USR\LOCAL\SRC\PROJECT1\FILE.C".
foo:>usr>local>src>project1>file.c.newest
Gareth McCaughan
> [Aside: Someone at Symbolics (I know who but am not sure he'd want his
> name in lights on this) used to suggest that we make up a new
> character which looked like a chalice and call it the 'host' character
> and use it as a separator instead of colon so that the separator
> didn't interfere with native operating system characters.
Superb (and, of course, insane). But <pedant>you'd want a paten,
not a chalice</pedant>.
...
> ]
--
Gareth McCaughan
.sig under construc
Pascal Bourguignon
Tim Bradshaw
> I'm happy to be able to mount NFS from MacOS servers, from MS-Windows
> servers, or Samba file systems from Linux or MS-WIndows servers, and
> in ALL cases, access the imported volumes with the same unix
> syntax. Come to think of it, the unix path syntax is like the logical
> path syntax: a uniformizing one.
Yes, you can make all filesystems look like the Unix filesystem.
Unfortunately the Unix filesystem is deficient and can't reliably
express a lot of things that one could want to express in a
filesystem. Syntactically: how do you distinguish between :UP and
:BACK in directory specifications (and why does it matter); between
files and directories; between two versions of a file? Semantically:
How do you do access control (no, don't tell me about chown); how do
you know when a file was backed up, and where to? How do you know
what's *in* a file or otherwise keep metadata about it? (Oh, and by
the way: actually, all these alien filesystem only look *nearly* like
the Unix one: even remote Unix filesystems don't really look like Unix
filesystems, becuase it's terribly hard to preserve the semantics over
a network connection, as anyone who has written non-trivial programs
that might need to use NFS knows.)
Of course, the Unix filesystem - along with the rest of Unix - is a
truly amazing feat of engineering. To get something even reasonably
competent, let alone with the simplicity and elegance of Unix and
decent performance to boot, to work on a machine as small as a PDP-11
is just a wonderful feat. We all have a lot to be grateful for:
instead of those hugely expensive DEC 10s we used to have, we can
almost buy *personal* PDP-11s nowadays, they're well under 100k for
quite a decent configuration, after all.
Oh, I forget myself. It's the 80s already, and we have these personal
32-bit workstations now. Well, we can probably afford to think about
using a more sophisticated filesystem now, can't we?
Well, no, tragically we can't. Linux has seen to it that the OS that
was nearly state of the art in 1972 is what we all think is state of
the art in 2003. Yes, rather than doing anything slightly new, we've
wasted 10 years slavishly reinventing a system that was obsolete 5
years before we started reinventing it, and dressed it all up as a
religion, as well. Now no one can even remember that there might have
been alternatives once: it's a Unix clone, or it's nothing. The very
suggestion that we might want to allow variant filesystems is
anathama: if it doesn't have (or nearly have) Unix semantics, burn it!
The tragedy is, that, of course, there is actually life in the Unix
filesystem. Solaris has real ACLs, and I think has or will soon have
user-definable file metadata. The Linux slaves have probably already
copied it, if they haven't already. Progress is being made, even in
this dark age.
--tim
Pascal Bourguignon
Tim Bradshaw <t...@cley.com> writes, OT:
> [...]
Nice rant, but you're forgetting one thing.
> The tragedy is, that, of course, there is actually life in the Unix
> filesystem. Solaris has real ACLs, and I think has or will soon have
> user-definable file metadata. The Linux slaves have probably already
> copied it, if they haven't already. Progress is being made, even in
> this dark age.
It's no more this dark age. We came out of the dark age.
What you're forgetting is the dark side of the force, I mean, the
forces of evil who closed and hide the sources. That' why there has
not been any progress in software for almost twenty years (apart for
the viruses and worms). Of course, freedom developers had to rewrite
from scratch something that was state of the art before the dark age:
there was no free source of anything equivalent available to further
research and progress!
Now that free sources are available for OS and application, research
and progress can continue from where it left in 1981.
To revert to the topic, you did not see my point:
On a unix system, users want to use unix pathnames.
The unix system therefore presents all file systems to the user with
the unix path syntax.
On a MS-DOS system, users want to use MS-DOS pathnames.
The MS-DOS system therefore presents all file systems to the user with
the MS-DOS path syntax.
On a MacOSX system, users want to use MacOSX pathnames.
The MacOSX system therefore presents all file systems to the user with
the MacOSX path syntax.
And:
It is crazy to want a system where you dynamically change the path
syntax depending on the place from where the files come. Ad
absurdum, (in the case of relaying NFS/Samba/AppleShare/whatever
this would lead you to write things like:
HOST:dir>her>home/pascal/Macintosh\ HD:Personal\ Folder:E:\\MYFILE.DOC
(a MS-DOS server publish its E: volume, which is mounted via samba on
a MacOS server on Macintosh\ HD:Personal\ Folder:E: and republished
along with the whole disk, which is mounted via AppleShare on a unix
system on /home/pascal/Macintosh\ HD and republished along with /home,
which is mounted (via NFS) on a VMS or whatever on HOST:dir>her>home).
Ok, this is an ad-absurdum, but I'm saying that it's the same to be
wanting to have in the same system paths that must be written as:
HOST1:dir>ect>ory>file.lisp
HOST2:dir/ect/ory/file.lisp
HOST3:dir\\ect\\ory\\file.lisp
HOST4:dir:ect:ory:file.lisp
just because HOST1 happens to be a remote VMS, HOST2 a remote unix,
HOST3 a remote MS-DOS and HOST4 a remote MacOS.
Why do you think the logical path names were invented???
And of course, the physical paths must containt the only syntax local
to the OS where we're running, and there there's no notion of host. So
I'm not surprised that: (pathname-host #P"/tmp") be nil, given that
Common-Lisp does not specify that something portably understandable by
all implementations on any OS be returned.
Let's traverse Alice's mirror and imagine a utopia where such a thing
would have been specified. I'd be happy to get on a unix system:
(pathname-host #P"/tmp")
=> (:unix "thalassa.informatimago.com")
or:
(pathname-host #P"Macintosh HD:Perso Files:")
=> (:macos "naiad.informatimago.com")
the more so if I can send these result to another lisp in Japan and
have it retrieve remotely the files on these hosts.
But as it has been remarked:
1- URL are not supported (just a fact),
2- URL have a unique UNIFORM syntax for all resources.
So when you want to fetch files on remote hosts, you use in ALL cases:
file://naiad.informatimago.com/Macintosh%20HD/Perso%20Files/
file://thalassa.informatimago.com/tmp
while these URLs will be converted by the servers into the local syntax.
james anderson
?
Pascal Bourguignon wrote:
>
>
> To revert to the topic, you did not see my point:
>
> On a unix system, users want to use unix pathnames.
> The unix system therefore presents all file systems to the user with
> the unix path syntax.
>
> On a MS-DOS system, users want to use MS-DOS pathnames.
> The MS-DOS system therefore presents all file systems to the user with
> the MS-DOS path syntax.
>
> On a MacOSX system, users want to use MacOSX pathnames.
> The MacOSX system therefore presents all file systems to the user with
> the MacOSX path syntax.
>
may i note that it is not our custom to submit to the royal user. we do not
actively use physical pathname namestrings. we use them only to specify
translations in a logical host definitions. we have followed this practice for
several years. if physical pathnames are presented to us in the listener, we
will occasionally cut-and-past them in the listener. under which circumstances
the namestring syntax does not matter to us.
> Why do you think the logical path names were invented???
so, if we use logical pathnames, and
> ...
>
> So when you want to fetch files on remote hosts, you use in ALL cases:
>
> file://naiad.informatimago.com/Macintosh%20HD/Perso%20Files/
> file://thalassa.informatimago.com/tmp
>
> while these URLs will be converted by the servers into the local syntax.
>
if we use urls, what reason do we have to require the implementation or the
application to impose or expect the same uniformity for physical pathname namestrings?
Christophe Rhodes
> may i note that it is not our custom to submit to the royal user. we
> do not actively use physical pathname namestrings. we use them only
> to specify translations in a logical host definitions. we have
> followed this practice for several years. if physical pathnames are
> presented to us in the listener, we will occasionally cut-and-past
> them in the listener. under which circumstances the namestring
> syntax does not matter to us.
I'd love to see you update your copy of libX11.so.1 using just logical
pathnames. Or .bash_profile, for that matter.
Or maybe you'd just put your head in the sand and say that those files
are irrelevant, in a bizarre manifestation of Sapir-Whorf?
Christophe Rhodes
> Christophe Rhodes wrote:
>
>> Pascal Bourguignon <sp...@thalassa.informatimago.com> writes:
>>
>>>Physical pathnames in lisp are the same as used in a unix shell, when
>>>the lisp implementation is on unix. At least, it should.
>> There is a very strong argument for Lisp implementations on Unix to
>> prepend a colon to the Unix pathname to generate the Lisp namestring.
>
> Why should it be like this?
Because that way the host component can be reliably parsed from Lisp
namestrings, rather than some weird DWIM heuristics applied.
Note that nowhere does it say that a Lisp namestring should correspond
exactly to an underlying OSlike pathname. It is simply a parseable
representation of something.
>> At least, there would be if current Lisp implementations on Unix
>> actually did anything interesting at all with the host field.
>
> This does not apply solely to UNIX. Since these days I am working
> mostly on Windows, I'd say that the same argument applies to other
> OSes as well. The truth is that a "new" spec should address
> essentially the Windows and the UNIX filesystems (given that Mac OS 9
> pathnames are bound to disappear,) plus UR{NIL} (with the proviso that
> networking issues have to be trated in a separate way.)
No, I don't think so. Just because all we have _today_ is effectively
(modulo the dying remnants of the SmugLispWeenies) Windows and Unixoid
wannabes doesn't mean that that's all we'll have ever.
Instead, the standard can be patched up fairly well by deleting the
unfeasible requirements in the specification of COMPILE-FILE-PATHNAME,
and fixing up the other inconsistencies that Paul Dietz is in the
process of discovering . Then, using the available latitude in
implementation details for pathnames, I'm fairly convinced that things
could actually work.
>> On the other hand, since the Common Lisp pathname system goes out of
>> its way to prevent using Unix pathnames -- not to mention URIs -- as
>> pathnames, it's not clear what can be gained in discussing the
>> semantics of Lisp pathnames on Unix besides a rather stong headache.
>
> I agree with this. However, in all fairness, UR{NIL} stuff was not
> known at the time of the writing of the ANSI spec.
No, but the Common Lisp pathname semantics were meant to be able to
express whatever pathname semantics were provided by the Operating
Environment.
Not that I blame the ANSI committee for running out of time, money and
patience.
james anderson
Christophe Rhodes wrote:
>
> james anderson <james.a...@setf.de> writes:
>
> > may i note that it is not our custom to submit to the royal user. we
> > do not actively use physical pathname namestrings. we use them only
> > to specify translations in a logical host definitions. we have
> > followed this practice for several years. if physical pathnames are
> > presented to us in the listener, we will occasionally cut-and-past
> > them in the listener. under which circumstances the namestring
> > syntax does not matter to us.
>
> I'd love to see you update your copy of libX11.so.1 using just logical
> pathnames.
we are still discussing the syntax of physical pathname namestrings in lisp?
in any case, we are at a loss as to what we would write into a shared library
from lisp at the moment,
> Or .bash_profile, for that matter.
but, for a bash profile, we can conceive of something which shouldn't hurt,
and demonstrate that there are at least two ways to use a logical pathname to
designate a file which contains in its name a character which cannot appear in
a logical pathname namestring.
Welcome to Macintosh Common Lisp Version 4.3.1! (nb. under os 9.1)
? (setf (logical-pathname-translations "unix")
`(("**;dotfile;*.*"
,(make-pathname :name ".*" :type :wild
:directory '(:absolute :wild-inferiors)))
("**;dot-*.*"
,(make-pathname :name ".*" :type :wild
:directory '(:absolute :wild-inferiors)))
("**;*.*" "**:*.*")))
(("**;dotfile;*.*" #P"**:*.*.*") ("**;dot-*.*" #P"**:*.*.*") ("**;*.*" "**:*.*"))
? (probe-file "unix:dotfile;bash_profile")
NIL
? (with-open-file (stream "unix:dotfile;bash_profile"
:direction :output
:if-exists :supersede
:if-does-not-exist :create)
(format stream "# i'm not sure what bash would want~%"))
NIL
? (probe-file "unix:dot-bash_profile")
#2P"entwicklung@paz:MCL 4.3.1:.bash_profile"
? (describe *)
#2P"entwicklung@paz:MCL 4.3.1:.bash_profile"
Type: PATHNAME
Class: #<BUILT-IN-CLASS PATHNAME>
TYPE: PATHNAME
%PATHNAME-DIRECTORY: (:ABSOLUTE "entwicklung@paz" "MCL 4.3.1")
%PATHNAME-NAME: ""
%PATHNAME-TYPE: "bash_profile"
?
which brings up the question, whether phyisical pathnames are themselves
sufficient. but that's a thread of its own. in any case, while
pathname-match-p and translate-pathname are not completely specified, they can
do more than we might think.
>
> Or maybe you'd just put your head in the sand and say that those files
> are irrelevant,
our head is not likely in the sand at the moment. we are orthographically
challenged enough as it is.
> in a bizarre manifestation of Sapir-Whorf?
on the contrary, were i pushed, i would have to admit deconstructivist
tendancies, and would sooner suggest that, despite that one cannot think about
something which one cannot express, given a coherent means of expression and
sufficient motivation, one may discover that one can express things which one
did not know that one could think about.
...
Christophe Rhodes
> Christophe Rhodes wrote:
>>
>> james anderson <james.a...@setf.de> writes:
>>
>> > may i note that it is not our custom to submit to the royal user. we
>> > do not actively use physical pathname namestrings. we use them only
>> > to specify translations in a logical host definitions. we have
>> > followed this practice for several years. if physical pathnames are
>> > presented to us in the listener, we will occasionally cut-and-past
>> > them in the listener. under which circumstances the namestring
>> > syntax does not matter to us.
>>
>> I'd love to see you update your copy of libX11.so.1 using just logical
>> pathnames.
>
> we are still discussing the syntax of physical pathname namestrings
> in lisp?
I'm not the one who brought up logical pathnames.
> in any case, we are at a loss as to what we would write into a shared library
> from lisp at the moment,
How about copying an upgrade from your vendor?
Copy File "[DEBIAN]:>POOL>MAIN>X>XFREE86>NEW>libX11.so.1" ":/usr/lib/libX11.so.1"
is how one might do it in a physical pathname parallel world.
>> Or .bash_profile, for that matter.
>
> but, for a bash profile, we can conceive of something which
> shouldn't hurt, and demonstrate that there are at least two ways to
> use a logical pathname to designate a file which contains in its
> name a character which cannot appear in a logical pathname
> namestring.
>
> Welcome to Macintosh Common Lisp Version 4.3.1! (nb. under os 9.1)
> ? (setf (logical-pathname-translations "unix")
> `(("**;dotfile;*.*"
> ,(make-pathname :name ".*" :type :wild
> :directory '(:absolute :wild-inferiors)))
> ("**;dot-*.*"
> ,(make-pathname :name ".*" :type :wild
> :directory '(:absolute :wild-inferiors)))
> ("**;*.*" "**:*.*")))
> [snip]
> ?
You know, I'm aware of the renaming tricks one can play with logical
pathname translations. I was hoping that the suggestion that one
might wish commonly to deal with files whose names are not under the
full control of the user could bring forth the realization that such
renaming workarounds are just that: workarounds; one shouldn't claim
that everything can conveniently be done with logical pathnames
without a suitable definition of "everything".
And in any case, it is not the dot that leads to unspecified behaviour
in logical pathnames (just confusing behaviour); the underscore is not
a portable pathname character. And yes, one can play the same game,
accessing .bash_profile through the pathname
":dotfile;bash;underscore;profile", but I hope you begin to see the
point.
> which brings up the question, whether phyisical pathnames are
> themselves sufficient. but that's a thread of its own. in any case,
> while pathname-match-p and translate-pathname are not completely
> specified, they can do more than we might think.
The question of whether physical pathnames are sufficient on Unix
(actually, I claim they are overspecified, because they force the
implementation to give semantics to the "type" concept which does not
exist in a standard Unix filesystem) is certainly relevant for
implementors hoping that community consensus will build that (minor)
revision of the Common Lisp standard is necessary.
Kent M Pitman
> Not that I blame the ANSI committee for running out of time, money and
> patience.
Note that the ANSI committee did not exactly run out of money, nor to
some degree out of patience. Harder to say about that last.
The committee per se did cost a little to run, but it was composed of
members and they ran out of money so they dropped out, in some sense
making the votes easier and easier ... (and probably worse and worse,
due to less good representation of the community, with mostly only the
vendors hanging in until the end). Part of the public review was run
while I was laid off, and I continued my work during that time.
old-Harlequin picked me up quickly, fortunately, and kept me funded to
continue that or it would have gotten harder. I bet it would have
continued to fund me, had we run for a bit longer, since it was not yet
in the financial difficulty that brought it down. And, for that
matter, I had some issues that I was wanting so badly (defsystem was
one) that when the committee insisted there was no time to do it,
I promised to cancel dates with my girlfriend just so that there was
budgeted "new time" to do it if they'd only let me. But no one trusted
that to happen. So the resource issue, and to some degree the patience
issue was not exhausted.
Patiences were running short, though, at the corporate level. Vendors
had been holding out for an ANSI standard. It divided the community,
and delayed our ability to claim certain moral high ground. And we had
feature-frozen in 1988, so by 1992 when we were doing nothing more than
desperately needed bug fixes (we added :external-format and a few
character-related issues at the request of our Japanese friends, we
added the LAMBDA macro and DEFINE-SYMBOL-MACRO in order to better support
ISLISP, etc.), people just wanted it over. It just needed to be done.
But I guess my point is that the "who" on behalf it needed to be done
was the community, not the committee.
As an incidental matter, had it not been done when it was, I doubt the
HyperSpec could have happened. And it's my impression that that seems
to have had an important cohesive force on the community in and of
itself, somewhat independent of the standard per se (although I can't
really quantify that and maybe I just like to delude myself into thinking
so because it was my baby).
But in any case, I think the production of CLHS, the creation of
various freeware versions of Lisp, the commitment of various vendors
to interoperation, etc. were all good effects that had been held
hostage, to some extent, to the big question of "when is the definitive
definition going to appear?" since people weren't going to invest in such
things absent a standard.
I've sometimes said that the importance of a standard is to allow
companies to go out of business gracefully. If you go into a store
and ask to buy "fred's proprietary language x", you're mostly not
going to find more than one vendor selling it. But if you make a
standard for language x, you may find multiple vendors. And this
contributes to stability of the language in important ways that
transcend individual vendors.
The standard had to come to an end in order for the community to move
ahead. And yet, the community moving ahead (including to embrace the
web, the rise of Linux, the fall of DEC Alpha, the conversion to DEC
Alpha, to name just a few platform issues), would necessarily make
some of the work we had frozen seem quaint. Things were always in flux
and it was always obvious that what we'd done to date could be repaired
with more time. It was just and always would be a race. I think in
appropriate historical context, we did ok.
But what I still find fascinating is that after so much change, there
are STILL people who are willing to talk as if there will be no change
in the future, and so they point to the operating systems of today
and say "couldn't we simplify the pathname system now that we have only
x and y and z feature" as if it was
(a) true that we'd beaten competition out of the market,
(b) good that we'd beaten competition out of the market,
(c) impossible for competition to ever need to return to the market, and
(d) impossible for competition to ever return to the market
whether we need it or not.
We learn from history that evolution favors momentary advantage over
long-term advantage. One well-placed survival trait can cause an
otherwise ill-prepared organism to survive and dominate. One
ill-omitted survival trait can cause an otherwise well-prepared
organism to die out in an untimely way. There are a great many useful
features lost in those operating systems and file systems the death of
which is implicitly celebrated by someone willing to say "couldn't we
now throw out a lot of this baggage and unify things". Common Lisp
was and is equipped to survive a great deal of back and forth while
such battles between file systems and operating systems are fought
out, and I would hope that at the first sign of calm in the
marketplace, we would not doff that protective shielding and say
"we'll never need this again", if for no other reason than that not
all of us who have used the "losers" in those battles think that the
winners are better than what went before. So some of us cling to the
hope that we might see better than Windows and/or Linux in the future.
(And no, I don't even just mean Lisp-based better things, though that
would be fun, too.)
james anderson
Christophe Rhodes wrote:
>
> james anderson <james.a...@setf.de> writes:
>
> > Christophe Rhodes wrote:
> >>
> >> james anderson <james.a...@setf.de> writes:
> >>
> >> > may i note that it is not our custom to submit to the royal user. we
> >> > do not actively use physical pathname namestrings. we use them only
> >> > to specify translations in a logical host definitions. we have
> >> > followed this practice for several years. if physical pathnames are
> >> > presented to us in the listener, we will occasionally cut-and-past
> >> > them in the listener. under which circumstances the namestring
> >> > syntax does not matter to us.
> >>
> >> I'd love to see you update your copy of libX11.so.1 using just logical
> >> pathnames.
> >
> > we are still discussing the syntax of physical pathname namestrings
> > in lisp?
>
> I'm not the one who brought up logical pathnames.
the point at issue was whether one should elevate physical pathnames to a
quasi-logical status. an aspect of the imperative was that the royal user
deems such syntactic uniformity necessary for their usual actions. this user
demurred, questioned the necessity, and suggested that, where uniformity is
necessary, logical pathnames usually suffice. where they do not, translations
accomplish much. where they do not suffice, this user has managed to survive,
above ground, usually by treating physical pathname namestrings as opaque
objects which are delivered and accepted by the user interface. i would accede
that there must have been occasions when i have resorted to pathname operators
for purposes other than constructing translation targets, but i cannot recall
when the last occasion was.
>
> > in any case, we are at a loss as to what we would write into a shared library
> > from lisp at the moment,
>
> How about copying an upgrade from your vendor?
> Copy File "[DEBIAN]:>POOL>MAIN>X>XFREE86>NEW>libX11.so.1" ":/usr/lib/libX11.so.1"
i do not customarily do that in a lisp listener.
were i to need to, then whatever physical pathname syntax the implementation
supported would either be able to name the file or it would not. were it
unable, it would likely be a structural issue rather than a lexical issue.
whether the implementation expressed the pathnames in the same syntax as used
by the common unix shells is, in itself, not material.
> is how one might do it in a physical pathname parallel world.
i do not disavow physical pathnames. i suggest only that their use does not
warrant the proposed form of standardization.
>
> ...
>
> one shouldn't claim
> that everything can conveniently be done with logical pathnames
> without a suitable definition of "everything".
i did not claim everything. i described active use. as in operating on them
programmatically. and that in response to the implications that the user
requires a uniformity in physical pathname syntax.
>
> And in any case, it is not the dot that leads to unspecified behaviour
> in logical pathnames (just confusing behaviour); the underscore is not
> a portable pathname character. And yes, one can play the same game,
> accessing .bash_profile through the pathname
> ":dotfile;bash;underscore;profile", but I hope you begin to see the
> point.
>
> > which brings up the question, whether phyisical pathnames are
> > themselves sufficient. but that's a thread of its own. in any case,
> > while pathname-match-p and translate-pathname are not completely
> > specified, they can do more than we might think.
>
> The question of whether physical pathnames are sufficient on Unix
> (actually, I claim they are overspecified, because they force the
> implementation to give semantics to the "type" concept which does not
> exist in a standard Unix filesystem) is certainly relevant for
> implementors hoping that community consensus will build that (minor)
> revision of the Common Lisp standard is necessary.
but remains a thread separate from one which concerns the extent to which any
given underlying os dictates the physical pathname syntax for a given lisp implementation.
take a couple of hours and spend them debugging simultaneously in a windows
lisp, a unix lisp, and a classic mac os lisp. i'd suggest more, but those are
the ones within reach of the little hole i'm sitting in. working from a single
source. maybe even just an hour. throw in a user interface which accepts both
quoted and unquoted pathnames. maybe a thought experiment suffices.
does physical namestring verisimilitude still matter?
...
Christophe Rhodes
> take a couple of hours and spend them debugging simultaneously in a
> windows lisp, a unix lisp, and a classic mac os lisp. i'd suggest
> more, but those are the ones within reach of the little hole i'm
> sitting in. working from a single source. maybe even just an
> hour. throw in a user interface which accepts both quoted and
> unquoted pathnames. maybe a thought experiment suffices.
>
> does physical namestring verisimilitude still matter?
Right. I think on this point we're probably in agreement :-)
Joe Marshall
> Of course, the Unix filesystem - along with the rest of Unix - is a
> truly amazing feat of engineering. To get something even reasonably
> competent, let alone with the simplicity and elegance of Unix and
> decent performance to boot, to work on a machine as small as a PDP-11
> is just a wonderful feat. We all have a lot to be grateful for:
> instead of those hugely expensive DEC 10s we used to have, we can
> almost buy *personal* PDP-11s nowadays, they're well under 100k for
> quite a decent configuration, after all.
Voltaire was correct: this truly *is* the best of all possible
worlds.
Edi Weitz
> Voltaire was correct: this truly *is* the best of all possible
> worlds.
<ot>
<nitpick>
That was Leibniz. Voltaire (in "Candide") made fun of him.
</nitpick>
</ot>
Kent M Pitman
Marco Antoniotti
Pascal Bourguignon wrote:
> Tim Bradshaw <t...@cley.com> writes, OT:
>
>>[...]
>
>
> Nice rant, but you're forgetting one thing.
>
>
>>The tragedy is, that, of course, there is actually life in the Unix
>>filesystem. Solaris has real ACLs, and I think has or will soon have
>>user-definable file metadata. The Linux slaves have probably already
>>copied it, if they haven't already. Progress is being made, even in
>>this dark age.
>
>
> It's no more this dark age. We came out of the dark age.
Yep!
>
...
>
>
> To revert to the topic, you did not see my point:
>
> On a unix system, users want to use unix pathnames.
> The unix system therefore presents all file systems to the user with
> the unix path syntax.
Yes and no.
>
> On a MS-DOS system, users want to use MS-DOS pathnames.
> The MS-DOS system therefore presents all file systems to the user with
> the MS-DOS path syntax.
Yes and no (what about UNC pathnames?)
>
> On a MacOSX system, users want to use MacOSX pathnames.
> The MacOSX system therefore presents all file systems to the user with
> the MacOSX path syntax.
Mac OS pathnames are at this point UNIX pathnames.
>
> Ok, this is an ad-absurdum, but I'm saying that it's the same to be
> wanting to have in the same system paths that must be written as:
>
> HOST1:dir>ect>ory>file.lisp
> HOST2:dir/ect/ory/file.lisp
> HOST3:dir\\ect\\ory\\file.lisp
> HOST4:dir:ect:ory:file.lisp
>
> just because HOST1 happens to be a remote VMS, HOST2 a remote unix,
> HOST3 a remote MS-DOS and HOST4 a remote MacOS.
Why not? I can live with that, given that you have logical pathnames
(which can be improved nevertheless)
>
> Why do you think the logical path names were invented???
ditto.
>
> And of course, the physical paths must containt the only syntax local
> to the OS where we're running, and there there's no notion of host. So
> I'm not surprised that: (pathname-host #P"/tmp") be nil, given that
> Common-Lisp does not specify that something portably understandable by
> all implementations on any OS be returned.
This is a problem in the spec. The spec should have specified an
"implementation dependent non-nil structure".
>
>
> But as it has been remarked:
>
> 1- URL are not supported (just a fact),
> 2- URL have a unique UNIFORM syntax for all resources.
>
> So when you want to fetch files on remote hosts, you use in ALL cases:
>
> file://naiad.informatimago.com/Macintosh%20HD/Perso%20Files/
> file://thalassa.informatimago.com/tmp
>
> while these URLs will be converted by the servers into the local syntax.
>
>
>
>
Ahem! What should
(pathname-directory
(parse-namestring "file://thalassa.informatigo.com/tmp"))
return?
Either you specify that or we are back to the starting point. UR{NIL}
or not. Moreover, even with UR{NIL} NOBODY wants to write
(open "file://localhost/some/dir/foo.lisp")
when
(open "/some/dir/foo.lisp")
will do.
Cheers
--
Marco Antoniotti
Christophe Rhodes
> Ahem! What should
>
> (pathname-directory
> (parse-namestring "file://thalassa.informatigo.com/tmp"))
>
> return?
Is this a trick question, or (assuming ordinary URIish semantics) is
(:ABSOLUTE) the answer? (as in, I can't work out how you would get
anything else)
Joe Marshall
It was a conscious descision to quote Voltaire rather than Leibniz.
-------------
When they were not arguing, the boredom was so fierce that one day the
old woman ventured to say: ``I should like to know which is worse,
being raped a hundred times by pirates, having a buttock cut off,
running the gauntlet in the Bulgar army, being flogged and hanged in
an auto-da-fé, being dissected and rowing in the galleys ---
experiencing, in a word, all the miseries through which we have passed
--- or else just sitting here and doing nothing?''
``It's a hard question'', said Candide.
Marco Antoniotti
Christophe Rhodes wrote:
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
>
>>Christophe Rhodes wrote:
>>
>>
>>>Pascal Bourguignon <sp...@thalassa.informatimago.com> writes:
>>>
>>>
>>>>Physical pathnames in lisp are the same as used in a unix shell, when
>>>>the lisp implementation is on unix. At least, it should.
>>>
>>>There is a very strong argument for Lisp implementations on Unix to
>>>prepend a colon to the Unix pathname to generate the Lisp namestring.
>>
>>Why should it be like this?
>
>
> Because that way the host component can be reliably parsed from Lisp
> namestrings, rather than some weird DWIM heuristics applied.
So, would you force people to write
(open ":foo/bar.lisp")
?
I don't think this will go down well. OTOH I am all for cleaning up all
the DWIM gotchas that you have in the pathname stuff.
(pathname-directory (parse-namestring "/tmp"))
on UNIX being one of them.
>
> Note that nowhere does it say that a Lisp namestring should correspond
> exactly to an underlying OSlike pathname. It is simply a parseable
> representation of something.
This is a very good argument. UR{NIL} could be a solution.
>
>
>>>At least, there would be if current Lisp implementations on Unix
>>>actually did anything interesting at all with the host field.
>>
>>This does not apply solely to UNIX. Since these days I am working
>>mostly on Windows, I'd say that the same argument applies to other
>>OSes as well. The truth is that a "new" spec should address
>>essentially the Windows and the UNIX filesystems (given that Mac OS 9
>>pathnames are bound to disappear,) plus UR{NIL} (with the proviso that
>>networking issues have to be trated in a separate way.)
>
>
> No, I don't think so. Just because all we have _today_ is effectively
> (modulo the dying remnants of the SmugLispWeenies) Windows and Unixoid
> wannabes doesn't mean that that's all we'll have ever.
Yes. In principle I agree, however, the masses must be accommodated :)
>
> Instead, the standard can be patched up fairly well by deleting the
> unfeasible requirements in the specification of COMPILE-FILE-PATHNAME,
> and fixing up the other inconsistencies that Paul Dietz is in the
> process of discovering . Then, using the available latitude in
> implementation details for pathnames, I'm fairly convinced that things
> could actually work.
I am all for that. But I still have the problem of
(pathname-device (parse-namestring "D:\\"))
in ACL and LW. Not to mention
(pathname-name (parse-namestring ".cshrc"))
on UNIX. I do not want *any* latitute in the implementation of these
matters. I just want *one* DWIM for these. I can even settle for
(pathname-directory (parse-namestring "UNIX:/tmp")) ==> (42)
as long as that is the one and only result I can expect; always (and
without looking at the file system :) )
Cheers
--
marco
Juan Jose Garcia-Ripoll
> I don't think this will go down well. OTOH I am all for cleaning up all
> the DWIM gotchas that you have in the pathname stuff.
> (pathname-directory (parse-namestring "/tmp"))
> on UNIX being one of them.
Many free lisps (CLISP, CMUCL, GCL, ECL, and maybe SBCL which I do not have in
my system) seem to agree on the fact that "/tmp" is parsed as a file name and
"/tmp/" as a directory name. I do not think any of them checks the filesystem
for that.
Juanjo
Kent M Pitman
> Christophe Rhodes wrote:
> > Marco Antoniotti <mar...@cs.nyu.edu> writes:
> >
> >>Christophe Rhodes wrote:
> >>
> >>
> >>>Pascal Bourguignon <sp...@thalassa.informatimago.com> writes:
> >>>
> >>>
> >>>>Physical pathnames in lisp are the same as used in a unix shell, when
> >>>>the lisp implementation is on unix. At least, it should.
> >>>
> >>>There is a very strong argument for Lisp implementations on Unix to
> >>>prepend a colon to the Unix pathname to generate the Lisp namestring.
> >>
> >>Why should it be like this?
> > Because that way the host component can be reliably parsed from Lisp
> > namestrings, rather than some weird DWIM heuristics applied.
>
> So, would you force people to write
>
> (open ":foo/bar.lisp")
>
> ?
I'd be happy to see #0p"..." parse relative to localhost as an extension
to the language.
But in practice on the Lisp Machine I don't recall ever writing ':'
initially. I just always knew that I could. Mostly I just set my
pathname defaults to be right so that ordinary namestrings would
parse right, since almost nothing has colons in it.
These days, I do a lot of work with a companion PC for my LispM and I
just set up file hosts 'C' and 'D' to open connections to the C or
D device of my local NT box, so
C:\foo.bar (or C:/foo.bar, since I accept both syntaxes)
really means file host 'C' which, coincidentally, is what LispWorks also
does.
> I don't think this will go down well. OTOH I am all for cleaning up
> all the DWIM gotchas that you have in the pathname stuff.
>
> (pathname-directory (parse-namestring "/tmp"))
>
> on UNIX being one of them.
Do you mean the lack of trailing slash?
I prefer that on file systems which have directories as files,
/foo would mean the file containing the dir info (which has peers
of /bar and /baz even if those aren't dirs) and /foo/ would mean
the directory one down from the root under the name 'foo' containing
files like /foo/x and /foo/x.lisp).
IMO there's only something wrong with pathname-directory if it's
intended to get (:ABSOLUTE "TMP") out of "/tmp". If, instead, it's
DIRECTORY that does this, that's another matter. I think DIRECTORY
should find exactly one file when you give it a non-wildcard file spec
and not a wild dir spec. That is, (directory #P"/tmp") should return
(#P"/tmp") where as (directory "#P/tmp/") or (directory "#P/tmp/*")
should return that directory's contents.
Doing otherwise gets into HUGE problems about merging rules.
> > Note that nowhere does it say that a Lisp namestring should
> > correspond
> > exactly to an underlying OSlike pathname. It is simply a parseable
> > representation of something.
>
> This is a very good argument. UR{NIL} could be a solution.
Heh. Never noticed that NIL there. Cute.
I don't think it's a solution, though. In general, never bind yourself
to a solution that is not committed to responding to your needs. I don't
think URN/URI/URL schemes are committed to naming files. Geez, they don't
even do a good job of naming files now in the few common operating systems.
> I am all for that. But I still have the problem of
>
> (pathname-device (parse-namestring "D:\\"))
>
> in ACL and LW.
This is an example of something that works badly in UR{NIL}.
> Not to mention
>
> (pathname-name (parse-namestring ".cshrc"))
>
> on UNIX. I do not want *any* latitute
[latitude]
> in the implementation of these
> matters.
But you can't control what different file systems do from within Lisp.
In some file systems, .lisp is an invalid filename. In others it's
an ordinary file with no extension. In others it's an invisible file.
If what you mean is no latitude in how this works on a per-file-system
basis, you can win. But if you mean across file systems, I don't think
so.
> I just want *one* DWIM for these. I can even settle for
>
> (pathname-directory (parse-namestring "UNIX:/tmp")) ==> (42)
>
> as long as that is the one and only result I can expect; always (and
> without looking at the file system :) )
You have to look at the file system if you ever want to write a program
that manipulates the file system on someone else's behalf.
There was a file system called Eunice that was layered on VAX VMS (I think),
which if I recall gave the illusion of mixed-case filenames, but by prefixing
each lowercase letter with a "$" in the filesystem, so that what seemed to
Lisp like "Foo" was really "F$O$O" or some such thing. We didn't at the
time we came out with Lisp know what people would use externally to support
the model you used from within Lisp--we left that to the vendor exactly
because it was too prone to variation.
It's ok to make a layered standard that someone can voluntarily adhere to,
and then to allow market pressure to select that. But it would be nice
if a later drift to another way of doing things voided only that layered
standard and not some corrected version of the central spec.
That means SOME people would have to look at the file system but perhaps
a lot of people wouldn't, if they stayed within the subset of file
systems that seem to use the contemporary common basis.
Karl A. Krueger
> The tragedy is, that, of course, there is actually life in the Unix
> filesystem. Solaris has real ACLs, and I think has or will soon have
> user-definable file metadata. The Linux slaves have probably already
> copied it, if they haven't already. Progress is being made, even in
> this dark age.
You are, of course, trolling, but for the benefit of those who don't
realize that you are: There is really a great deal of work being done
on Linux filesystems above and beyond POSIX ACLs. Try Googling for any
of the following terms:
SELinux MAC
Intermezzo
ReiserFS
--
Karl A. Krueger <kkru...@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
Nikodemus Siivola
> Many free lisps (CLISP, CMUCL, GCL, ECL, and maybe SBCL which I do not have in
> my system) seem to agree on the fact that "/tmp" is parsed as a file name and
> "/tmp/" as a directory name. I do not think any of them checks the filesystem
> for that.
No. But some lisps will implicitly convert #p"/tmp" (file) into
#p"/tmp/" (directory) in the middle of some operation -- TRUENAME
being the common case.
Cheers,
-- Nikodemus
Juan Jose Garcia-Ripoll
That is rather counterintuitive to me. I would rather get an error message,
or leave the pathname unchanged in systems that allow me to treat a directory
as a file. (Although even the latest option is questionable).
[ECL]> (truename "/tmp")
Filename "/tmp" actually points to a directory
Broken at TRUENAME.
[ECL]> (truename "/tmp/")
#P"/tmp/"
Top level.
[CLISP]> (truename "/tmp")
*** - TRUENAME: "/tmp" names a directory, not a file
[CLISP]> (truename "/tmp/")
#P"/tmp/"
[CMUCL]* (truename "/tmp")
#p"/tmp"
Pascal Bourguignon
james anderson <james.a...@setf.de> writes:
> but remains a thread separate from one which concerns the extent to
> which any given underlying os dictates the physical pathname syntax
> for a given lisp implementation.
>
> take a couple of hours and spend them debugging simultaneously in a windows
> lisp, a unix lisp, and a classic mac os lisp. i'd suggest more, but those are
> the ones within reach of the little hole i'm sitting in. working from a single
> source. maybe even just an hour. throw in a user interface which accepts both
> quoted and unquoted pathnames. maybe a thought experiment suffices.
>
> does physical namestring verisimilitude still matter?
You could even simplify your experiment and just try to debug them
simultaneously on the SAME unix OS with ONLY two different
implementations of Common Lisp.
I've not used MacOS since the advent of NeXTSTEP and I just don't use
MSDOS/MS-Windows since 1985. My gripes are with the differences
between implementations on UNIX. What I'd like to see is a new
version of Common Lisp Standard that would try to eliminate all
unspecified or undefined parts, if only by noting that sub-standards
shall be specified for target platforms. We could specify meaningful
conversions and convention between logical path names and physical
path names in POSIX or in UNIX platform, and the same could be done in
MS-Windows (and if it matters, on MacOS and VMS). What's dreadful are
the divergent implementations the standard allow on the same platform.
(And of course, all objects that can be named in the host file systems
should be namable in logical paths too, otherwise there will be strong
incentive to use C to write generic tools instead of Common-Lisp).
Pascal Bourguignon
> But you can't control what different file systems do from within Lisp.
> In some file systems, .lisp is an invalid filename. In others it's
> an ordinary file with no extension. In others it's an invisible file.
>
> If what you mean is no latitude in how this works on a per-file-system
> basis, you can win. But if you mean across file systems, I don't think
> so.
We're meaning : no latitude inside a given platform.
There should be substandards for Common-Lisp on POSIX
Common-Lisp on unix
Common-Lisp on MS-Windows
Common-Lisp on MacOS
Common-Lisp on VMS
etc.
Pascal Bourguignon
> Pascal Bourguignon wrote:
> Yes and no (what about UNC pathnames?)
> > On a MacOSX system, users want to use MacOSX pathnames.
> > The MacOSX system therefore presents all file systems to the user with
> > the MacOSX path syntax.
>
> Mac OS pathnames are at this point UNIX pathnames.
Oops, indeed I wanted to write MacOS there.
> > Ok, this is an ad-absurdum, but I'm saying that it's the same to
> > be
> > wanting to have in the same system paths that must be written as:
> > HOST1:dir>ect>ory>file.lisp
> > HOST2:dir/ect/ory/file.lisp
> > HOST3:dir\\ect\\ory\\file.lisp
> > HOST4:dir:ect:ory:file.lisp
> > just because HOST1 happens to be a remote VMS, HOST2 a remote
> > unix,
> > HOST3 a remote MS-DOS and HOST4 a remote MacOS.
>
> Why not? I can live with that, given that you have logical pathnames
> (which can be improved nevertheless)
One reason: because there is no way to know from a string "HOSTn" what
syntax should be obeyed to build a path beginning with "HOSTn:". And
think about it: you could well have such syntax as:
<host> ':' '(' <file> ')' { 'in' <directory> } [ 'of' 'type' <type> ]
[ 'version' ( 'latest' | 'oldest' | <number> )
or anything more or less complex.
> > Why do you think the logical path names were invented???
>
> ditto.
So, that's why logical path names were invented: you write:
"HOST1:DIR;ECT;ORY;FILE.LISP"
and you get one or the other.
But now, please name me one Common-Lisp implementation where:
(translate-logical-pathname "HOST1:DIR;ECT;ORY;FILE.LISP" )
(translate-logical-pathname "HOST2:DIR;ECT;ORY;FILE.LISP" )
don't return two physical pathnames with the SAME syntax.
> > And of course, the physical paths must containt the only syntax
> > local
> > to the OS where we're running, and there there's no notion of host. So
> > I'm not surprised that: (pathname-host #P"/tmp") be nil, given that
> > Common-Lisp does not specify that something portably understandable by
> > all implementations on any OS be returned.
>
> This is a problem in the spec. The spec should have specified an
> "implementation dependent non-nil structure".
>
> > But as it has been remarked: 1- URL are not supported (just a
> > fact),
> > 2- URL have a unique UNIFORM syntax for all resources.
> > So when you want to fetch files on remote hosts, you use in ALL
> > cases:
> > file://naiad.informatimago.com/Macintosh%20HD/Perso%20Files/
> > file://thalassa.informatimago.com/tmp
> >
> > while these URLs will be converted by the servers into the local syntax.
>
> Ahem! What should
>
> (pathname-directory
> (parse-namestring "file://thalassa.informatigo.com/tmp"))
>
> return?
Nothing. That's my point here: even for URL, the relevant standard
specify that the entity who interprets them is the server, not the
client.
BUT! There is ONE standard for the syntax of URL which allows the
client to build URLs for ALL servers, whatever the syntax used by the
servers.
> Either you specify that or we are back to the starting point. UR{NIL}
> or not. Moreover, even with UR{NIL} NOBODY wants to write
>
> (open "file://localhost/some/dir/foo.lisp")
>
> when
> (open "/some/dir/foo.lisp")
>
> will do.
>
> Cheers
> --
> Marco Antoniotti
>
--
Paul Foley
> To revert to the topic, you did not see my point:
> On a unix system, users want to use unix pathnames.
> The unix system therefore presents all file systems to the user with
> the unix path syntax.
Oh yes...and what happens if the foreign filename syntax allows
slashes in its filenames, or supports versioning, or something?
> On a MS-DOS system, users want to use MS-DOS pathnames.
> The MS-DOS system therefore presents all file systems to the user with
> the MS-DOS path syntax.
And what happens when the file name contains a backslash or some other
character that's illegal in Windows file names but perfectly OK on Unix?
> On a MacOSX system, users want to use MacOSX pathnames.
> The MacOSX system therefore presents all file systems to the user with
> the MacOSX path syntax.
And what happens when the file name contains a colon ... ?
> It is crazy to want a system where you dynamically change the path
> syntax depending on the place from where the files come. Ad
> absurdum, (in the case of relaying NFS/Samba/AppleShare/whatever
> this would lead you to write things like:
> HOST:dir>her>home/pascal/Macintosh\ HD:Personal\ Folder:E:\\MYFILE.DOC
No you wouldn't, because (a) NFD makes filenames look like Unix
filenames, so Lisp would necessarily use that syntax; and (b) even if
that weren't so, it doesn't make sense to switch hosts in the middle
of a pathname, so you wouldn't get pathnames with multiple syntaxes
like that. [Presumably you'd have just XHOST:E:\\MYFILE.DOC, or
XHOST:\\MYFILE.DOC or something]
> Ok, this is an ad-absurdum, but I'm saying that it's the same to be
> wanting to have in the same system paths that must be written as:
> HOST1:dir>ect>ory>file.lisp
> HOST2:dir/ect/ory/file.lisp
> HOST3:dir\\ect\\ory\\file.lisp
> HOST4:dir:ect:ory:file.lisp
> just because HOST1 happens to be a remote VMS, HOST2 a remote unix,
> HOST3 a remote MS-DOS and HOST4 a remote MacOS.
Why do you insist on conflating network hosts and pathname hosts? I
have three different filesystems on one Linux machine...yes, Linux can
mount DOS partitions, etc., into the Unix file system and make them
look sort of vaguely like Unix (modulo file permissions are screwed,
some characters are illegal, text files have CR characters at the end
of every line and sometimes have noise on the end of the file, etc.),
but if I wanted to access them from Lisp I'd much rather have Lisp
hosts handling them that understood their native syntaxes.
> And of course, the physical paths must containt the only syntax local
> to the OS where we're running, and there there's no notion of host.
??
> But as it has been remarked:
> 1- URL are not supported (just a fact),
> 2- URL have a unique UNIFORM syntax for all resources.
3- URLs didn't exist when CL was designed.
> So when you want to fetch files on remote hosts, you use in ALL cases:
(not (equal pathname-host network-host))
--
You don't have to agree with me; you can be wrong if you want.
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>"))
Pascal Bourguignon
> On 10 Dec 2003 05:14:04 +0100, Pascal Bourguignon wrote:
>
> > To revert to the topic, you did not see my point:
>
> > On a unix system, users want to use unix pathnames.
> > The unix system therefore presents all file systems to the user with
> > the unix path syntax.
>
> Oh yes...and what happens if the foreign filename syntax allows
> slashes in its filenames, or supports versioning, or something?
There are rules, that are edicted by some normative organization, that
are applied. For example, in the case of MacOS, Apple did document and
specify guidelines about how to process Macintosh file and names. They
developed file formats for their forked files (AppleSingle,
AppleDouble, AppleTriple file formats) and naming conventions.
In the case of the slash, since it plays a role similar to the colon
in MacOS, they're swapped (but there are rules because the use of
colon in MacOS is not equivalent to that of the slash in unix).
So, a file named: "Macintosh HD:My Picts:Picture of 28/10/2003" on MacOS
could be named: "/mnt/mac/Macintosh HD/My Picts/Pictures of 28:10:2003"
on unix.
> > On a MS-DOS system, users want to use MS-DOS pathnames.
> > The MS-DOS system therefore presents all file systems to the user with
> > the MS-DOS path syntax.
>
> And what happens when the file name contains a backslash or some other
> character that's illegal in Windows file names but perfectly OK on Unix?
idem
Once upon a time, I've used NFS between MS-Windows-3.11 and SCO unix
without any problem.
> > On a MacOSX system, users want to use MacOSX pathnames.
> > The MacOSX system therefore presents all file systems to the user with
> > the MacOSX path syntax.
>
> And what happens when the file name contains a colon ... ?
See above.
> > It is crazy to want a system where you dynamically change the path
> > syntax depending on the place from where the files come. Ad
> > absurdum, (in the case of relaying NFS/Samba/AppleShare/whatever
> > this would lead you to write things like:
>
> > HOST:dir>her>home/pascal/Macintosh\ HD:Personal\ Folder:E:\\MYFILE.DOC
>
> No you wouldn't, because (a) NFD makes filenames look like Unix
> filenames, so Lisp would necessarily use that syntax; and (b) even if
> that weren't so, it doesn't make sense to switch hosts in the middle
> of a pathname, so you wouldn't get pathnames with multiple syntaxes
> like that. [Presumably you'd have just XHOST:E:\\MYFILE.DOC, or
> XHOST:\\MYFILE.DOC or something]
>
> > Ok, this is an ad-absurdum, but I'm saying that it's the same to be
> > wanting to have in the same system paths that must be written as:
>
> > HOST1:dir>ect>ory>file.lisp
> > HOST2:dir/ect/ory/file.lisp
> > HOST3:dir\\ect\\ory\\file.lisp
> > HOST4:dir:ect:ory:file.lisp
>
> > just because HOST1 happens to be a remote VMS, HOST2 a remote unix,
> > HOST3 a remote MS-DOS and HOST4 a remote MacOS.
>
> Why do you insist on conflating network hosts and pathname hosts?
I don't insists. I'm just showing the absurdity of it!
> I
> have three different filesystems on one Linux machine...yes, Linux can
> mount DOS partitions, etc., into the Unix file system and make them
> look sort of vaguely like Unix (modulo file permissions are screwed,
> some characters are illegal, text files have CR characters at the end
> of every line and sometimes have noise on the end of the file, etc.),
> but if I wanted to access them from Lisp I'd much rather have Lisp
> hosts handling them that understood their native syntaxes.
>
> > And of course, the physical paths must containt the only syntax local
> > to the OS where we're running, and there there's no notion of host.
>
> ??
>
> > But as it has been remarked:
>
> > 1- URL are not supported (just a fact),
>
> > 2- URL have a unique UNIFORM syntax for all resources.
>
> 3- URLs didn't exist when CL was designed.
>
> > So when you want to fetch files on remote hosts, you use in ALL cases:
>
> (not (equal pathname-host network-host))
Perhaps in VMS or some other old OS the notion of network host was
significant (and a path would NAME a remote host and browse their file
systems). But I'm not observing this. All I see is file sharing and
LOCAL paths and path syntax.
Indeed, it seems to me an important simplification and abstraction to
show the world seamlessly and uniformly thru the spectacles of local
conventions.
Kent M Pitman
> AFAIK, no current CL implementation supports multiple physical hosts
Symbolics' ANSI Common Lisp does. I have one running on the desk behind
me. I even use it to debug portable code sometimes.
What does it mean to be current?
It runs. It runs correctly.
Does it deviate? Once in a while.
Do other CL's deviate? Yes.
Does it have bugs? A small number.
Can you obtain support to get fixes if you need them? I'm sure you can.
Does it run at the same speed as Lisp on some other box? Depends on the
processor, but probably not.
Is speed a requirement of conformance? Nope.
Does it have a live user community? Yep. (And not just me.)
I wish people would stop trying to universally quantify across
implementations. Old implementations are allowed to stay and
new ones to arrive. Trying to name the ones you know and use
in your own experience denies (a) the past, (b) the future, and
(c) the possibility of things today outside of your own experience.
It is not even a requirement of a conforming implementation that the
implementor tell anyone that he/she created it. This goes to the very
heart of what it means for there to be a public standard. Ironically,
the private nature of the public denies your ability to quantify and
control it. (This is one reason that many governments fear privacy.
The more you know about something, the more you can control it. And,
in due relation, it's one of the many reasons that private people seek
not to have their privacy invaded: they have no desire to lose their
right to deviate from some gratuitously established norm.)
> (of different kinds; LispWorks on Windows has a host for each drive,
> but they're all the same kind of thing), so of course all logical
> pathname translations bottom out in a physical pathname on the single
> supported physical host, and they all have the same syntax.
I'm not sure I see your point here. Is there some specific action on
someone's part advocated on the basis of this controversial claim you've
made?
Variant implementations are not to be beaten into the ground, they are
to be permitted their right to exist. Our language was built around
tolerance for deviation of a variety of kinds, and thank goodness it was.
I recall a very early presentation by Steele about Java and how it was
going to run EXACTLY the same on every implementation and get rid of this
whole business of having to debug for each platform. I recall stopping
him after the talk and asking "If I have a terminal with a different
resolution than someone else, are you going to make there be more pixels
on my console or fewer on the other person's? Because if not, then either
Java was going to run differently and what you just said isn't true, or
else they were going to run the same and you were going to not work
correctly on some devices." He didn't have a very good answer to that.
I'm forever grateful that CL doesn't make portability claims like
"this will behave the same for all platforms". I'm glad that instead it
gives you a framework for REPRESENTING YOUR INTENT and for OBSERVING THE
DIFFERENCES that occur in the things that vary across implementations,
to include character sets, numerical representation, pathname details,
etc. If it falls short, it's not for lack of having tried. Trying to
beat everything into a "one size fits all" configuration is the very
essence of "deciding not to try".
If we had it to redesign today, would we have picked different ways of
addressing that same variation? Probably we'd have done some things
better. But you know, I bet a lot of things we'd have done worse.
Because back in the dank, dark, distant past that seems so icky to
proponents of Let's Just Do It One Way, we really understood diversity
and its purpose. And while there are some legitimately new concepts
(like URLs) and some concepts that seem to have gone to the side for
now (like devices and versions), we didn't have enough experience with
what was to come to claim we were experts in future history. So we
legislated conservatively. Now there's been a mere decade or two of
history to follow and already we have legions of people who have grown
up never seeing change because the local politics of the day is to not
allow much choice in the market, and those legions of people confuse
that with a promise that the world will always remain the same way.
Perhaps it will for quite a while. But that's not forward-thinking.
It reminds me more of someone who grew up under the modern electrical
system saying "Why is the voltage a symbolic constant and not just
110?" It's not like the electric company is going to change it. (And
they're not very likely to, btw.) But it turns out Columbus was
right, and there really are people who use 220 elsewhere in the world.
(Oops, he discovered the 110 world, we didn't discover his 220 world.
Silly me for thinking you could see it either way. I must remember
not to think of the world in such a natively American-centric way...)
But my point is that the 220 world isn't likely to change either. And
I don't know that any good is served by one world trying bludgeon the
other out of existence. Would some processes be simplified if
everyone did the same thing? Sure. But how do we equitably decide
who is backward-thinking and who is forward-thinking? A headcount?
Is that a good metric?
We live in a hopefully-unalterably pluralistic society. It's about
time we started to take the "live and let live" philosophy to heart
except where all corners of the universe are saying "we want out of
the corner we're in". It's one thing if some people have b&w screens
only because they can't afford color, as happened with TV, and we hope
one day everyone will upgrade. It's quite another if some people have
file systems with versioning and people who never got to use
versioning are scared by it and want to define it out of existence
without trying it. Pluralism is intended to allow little enclaves of
progress to test out an idea and gradually market it. Such new ideas
will ALWAYS start small. Sometimes they will grow and be beaten back.
Sometimes they'll be beaten away entirely and have to be reinvented.
But the goodness or badness of the idea isn't about how many people
use it. It's about whether it's even conceivably rational to use it
if you have it. That's what will decide whether people protect and
defend it. That's what will cause it to come back if you kill off
every last defender.
Thank goodness for Unicode, for example, even though a lot of us don't
use it, so that others may. But the one thing that bugs me about Unicode
is that it was built by a bunch of people concerned that some people would
be otherwise-outcasts from the ability to represent their languages and
yet it's still too small to represent all languages, and at least
some of those very same people are willing to commit to others the same
sin they didn't want to commit to themselves. So you find languages
that simply define that Unicode is enough. (I think I recall that
Dylan does this.) Which is wrong. Unicode is good as an implementation
of tolerance, but not it loses its goodness when wielded as as an
implementation of confinement.
I'm all for people mucking around with pathname specs in ways that improve
our ability to use pathnames without denying the breadth of things out
there in the real world that must be accomodated...
Kent M Pitman
> Indeed, it seems to me an important simplification and abstraction to
> show the world seamlessly and uniformly thru the spectacles of local
> conventions.
This was (apparently) the conclusion of the character set world,
and it seems a good one.
"Internationalization" is a process whereby programs are made able to
tolerate changes in locale. Programs are written by people who
understand a great deal more about the whole product development
and delivery process, including the idea of rehosting on different
platforms, varying user interfaces, etc.
Yet in the end, a product is "localized" by allowing a veneer on the
top that permits users in a given locale to use their own local customs
and conventions for interface reference. Internally? Often still quite
general purpose. But for the users, sometimes this limits the generality.
In Lisp, ever since forever, there has been a blurring of who the "user"
is. I can remember in 1978 when I first came to the MACSYMA group at
the MIT Lab for Computer Science (where I later wrote the Revised Maclisp
Manual), the terminology came up in our writing doc of things: who is
this person who we keep calling "the user". We often meant to say
"the programmer" but we didn't have a whole industry of people who'd gone
to school actually studying the art of documenting such things, so we had
to make up the distinction as we went along. C programmers know who they
are: they're the ones who can put the programs in. C application users
know who they are--they're the ones who are stuck using what came out and
have no ability to inject more program. But in Lisp, since EVAL and
COMPILE-FILE and LOAD and all that goodness are left around, the
distinctions are blurred, and we often find ourselves thinking that if we
are "forced to write" (open ":foo.lisp") that this is a "horrible travesty"
that no one would ever put up with. But we are programmers. People write
far more cumbersome things routinely in other languages. Here we're
fussing over a single character "out of place" that seems all too
cumbersome. That's nuts.
Nothing keeps you, the programmer, in a user interface from writing
(PARSE-NAMESTRING (READ-LINE) *MY-DEFAULT-HOST*)
so that the user never has to do this.
And in some cases, as was the case on the Lisp Machine, users _want_
the ability to name any host on the net. The Lisp Machine would have
been a sadly useless device if all it could talk to was its own (fun
but disconnected) file system. The cool thing about the Lisp Machine
was how much better it was at manipulating files remotely than many
native shells.... We often wished we could write our shells in Lisp on
a TOPS-20, but the Lisp Machine, effectively, let us do that.
So yes, let's keep the notion of programmer and user straight in this
discussion, and let's allow it to be a product choice to localize if
that's desirable. Or to expose the general purpose core, if that's
desirable. It should not be a choice forced by the language, which
doesn't know ..
I personally think the real problem is the lack of the operation
(STRING-FOR-HOST pathname host) => string
which should be the inverse of PARSE-NAMESTRING with a non-NIL
host argument. Absent this operation, everyone keeps trying to wish
that the other operations provided would somehow achieve this function.
And that's where the whole things starts to unravel. [I'm compelled
to note that the LispM had this operation, as a :STRING-FOR-HOST message
you could SEND using Zetalisp, and I think probably also
later in New Flavors as an FS:STRING-FOR-HOST generic function. Its
absence is not due to Zetalisp, it's due to the "subsetting" CL
committee folk insisted on doing, wishing NAMESTRING were enough, and
not seeing (exactly because most had only one file system) that
it wasn't.]
Marco Antoniotti
Juan Jose Garcia-Ripoll wrote:
Exactly my point. Given a certain HOST the PARSE-NAMESTRING (and -
looks like) the TRUENAME rules should be portable.
Cheers
--
Marco
Marco Antoniotti
Pascal Bourguignon wrote:
> Kent M Pitman <pit...@nhplace.com> writes:
>
>>But you can't control what different file systems do from within Lisp.
>>In some file systems, .lisp is an invalid filename. In others it's
>>an ordinary file with no extension. In others it's an invisible file.
>>
>>If what you mean is no latitude in how this works on a per-file-system
>>basis, you can win. But if you mean across file systems, I don't think
>>so.
>
>
> We're meaning : no latitude inside a given platform.
>
> There should be substandards for Common-Lisp on POSIX
> Common-Lisp on unix
> Common-Lisp on MS-Windows
> Common-Lisp on MacOS
> Common-Lisp on VMS
> etc.
Thank you, thank you, merci, grazie, obrigado, gracias, euXaristw, arigato!
Cheers
--
Marco
Pascal Bourguignon
> Paul Foley <s...@below.invalid> writes:
>
> > AFAIK, no current CL implementation supports multiple physical hosts
>
> Symbolics' ANSI Common Lisp does. I have one running on the desk behind
> me. I even use it to debug portable code sometimes.
> [...]
> Variant implementations are not to be beaten into the ground, they are
> to be permitted their right to exist. Our language was built around
> tolerance for deviation of a variety of kinds, and thank goodness it was.
>
> I recall a very early presentation by Steele about Java and how it was
> going to run EXACTLY the same on every implementation and get rid of this
> whole business of having to debug for each platform. I recall stopping
> him after the talk and asking "If I have a terminal with a different
> resolution than someone else, are you going to make there be more pixels
> on my console or fewer on the other person's? Because if not, then either
> Java was going to run differently and what you just said isn't true, or
> else they were going to run the same and you were going to not work
> correctly on some devices." He didn't have a very good answer to that.
> I'm forever grateful that CL doesn't make portability claims like
> "this will behave the same for all platforms". I'm glad that instead it
> gives you a framework for REPRESENTING YOUR INTENT and for OBSERVING THE
> DIFFERENCES that occur in the things that vary across implementations,
> to include character sets, numerical representation, pathname details,
> etc. If it falls short, it's not for lack of having tried. Trying to
> beat everything into a "one size fits all" configuration is the very
> essence of "deciding not to try".
You must make things _explicit_ to avoid problems. For example for
the size AND resolution of a bitmap screen, there is no problem of
portability to different screen size and resolutions if the system
does not assume an implicit size or an implicit resolution and
_explicitely_ exports primitives to get:
- the list of screens (there can be more than one!),
- for each screen:
- the number of vertical pixels,
- the number of horizontal pixels,
- the vertical resolution,
- the horizontal resolution,
- the "depth" of the screen:
- the number of color plane,
- list of number of bits per pixel per color plane.
(just a little exercise in explicting things out).
So yes, we're probably missing a (STRING-FOR-HOST pathname host)
function, and explicitly allowing and managing several kind of
physical host in the same lisp image (even if 99% of the
implementations have only one physical host ever).
> [...]
> I'm all for people mucking around with pathname specs in ways that improve
> our ability to use pathnames without denying the breadth of things out
> there in the real world that must be accomodated...
--
Pascal Costanza
Pascal Bourguignon wrote:
> You must make things _explicit_ to avoid problems. For example for
> the size AND resolution of a bitmap screen, there is no problem of
> portability to different screen size and resolutions if the system
> does not assume an implicit size or an implicit resolution and
> _explicitely_ exports primitives to get:
[...]
I am not following the thread wrt pathnames, so I don't know if this is
related, but: Knowing the size and resolution of the screen is not
sufficient. As soon as the size of a screen crosses a certain boundary
you have to change the UI approach. The desktop metaphor, for example,
doesn't work well on PDAs or cell phones.
This means that you cannot solve UI issues in a strictly
platform-independent way. (At least AFAIK.)
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Kent M Pitman
> Pascal Bourguignon wrote:
>
> > You must make things _explicit_ to avoid problems. For example for
> > the size AND resolution of a bitmap screen, there is no problem of
> > portability to different screen size and resolutions if the system
> > does not assume an implicit size or an implicit resolution and
> > _explicitely_ exports primitives to get:
> [...]
>
> I am not following the thread wrt pathnames, so I don't know if this
> is related, but: Knowing the size and resolution of the screen is not
> sufficient. As soon as the size of a screen crosses a certain boundary
> you have to change the UI approach. The desktop metaphor, for example,
> doesn't work well on PDAs or cell phones.
>
> This means that you cannot solve UI issues in a strictly
> platform-independent way. (At least AFAIK.)
Indeed.
And are all fonts guaranteed to be available on all platforms? Does
Java magically arrange for licenses? Or does it just forbid you from
using fonts at any location that might not be available everywhere?
And what about speakers...
I mean, seriously, this is a real cop out to say that the program would
work the same if all of its inputs were the same. There are too many
variables for this to be a meaningful claim. When people say code is
platform-independent, they don't mean "runs the same on any platform
that is 100% identical in detail to the one the app was debugged on".
They mean "runs the same on any platform [and no more fine print goes here]".
It's possible for people who are in CYA mode here to retroactively claim
that's not what they meant. But really, it's what the community inferred
until it got some sense. And once the community realized what was really
meant, they learned not to trust it". And in particular they learned to
distrust phrases like "write once, run anywhere", replacing them instead
with more cynical but more predictive phrases like "write once, debug
everywhere".
Paul Dietz
> And in particular they learned to
> distrust phrases like "write once, run anywhere", replacing them instead
> with more cynical but more predictive phrases like "write once, debug
> everywhere".
"Write once, run away."
Paul
Pascal Bourguignon
> Pascal Bourguignon wrote:
>
> > You must make things _explicit_ to avoid problems. For example for
> > the size AND resolution of a bitmap screen, there is no problem of
> > portability to different screen size and resolutions if the system
> > does not assume an implicit size or an implicit resolution and
> > _explicitely_ exports primitives to get:
> [...]
>
> I am not following the thread wrt pathnames, so I don't know if this
> is related, but: Knowing the size and resolution of the screen is not
> sufficient. As soon as the size of a screen crosses a certain boundary
> you have to change the UI approach. The desktop metaphor, for example,
> doesn't work well on PDAs or cell phones.
>
> This means that you cannot solve UI issues in a strictly
> platform-independent way. (At least AFAIK.)
But then there are more considerations. For example, my first PDA is
a 64 MB RAM 400 MHz machine. I DO expect it to be able to multitask
(and don't get it) and while I don't expect to move and resize windows
on its 320x320 screen most problems come from applications that don't
expect such a BIG real estate (and the increased resolution). Note
that there are PDAs with 320x480 screen that come quite close to the
512x342 of the original Macintosh. I'd say that the choice of GUI
flavor has more to do with the usage pattern than the actual
capability of the hardware.
Tim Bradshaw
> It's no more this dark age. We came out of the dark age.
Oh no, I don't think so. Computing has *never* been out of the dark
ages (don't assume I'm some kind of 36-bit-golden-ager please).
> What you're forgetting is the dark side of the force, I mean, the
> forces of evil who closed and hide the sources. That' why there has
> not been any progress in software for almost twenty years (apart for
> the viruses and worms). Of course, freedom developers had to rewrite
> from scratch something that was state of the art before the dark age:
> there was no free source of anything equivalent available to further
> research and progress!
(a) There *was* no `before the dark age';
(b) Near-functional BSD sources were available circa 1990 and
functional ones not much later (91 or 92?). So tell me, *why* did
Linux reinvent it all? Maybe because he couldn't think of
anything more interesting to do.
> Why do you think the logical path names were invented???
To provide a way of portably naming files which was just good enough
to let you load code, of course. Not to provide a general purpose
portable pathname facility.
Never mind, you won't understand: the worms have eaten your brain and
are chewing their way out through your eyes.
--tim
Tim Bradshaw
> AFAIK, no current CL implementation supports multiple physical hosts
> (of different kinds; LispWorks on Windows has a host for each drive,
> but they're all the same kind of thing), so of course all logical
> pathname translations bottom out in a physical pathname on the single
> supported physical host, and they all have the same syntax.
LispWorks does on Windows:
CL-USER 1 > (type-of #p"//fs/tfb-project/tmp/foo.bar")
system::unc-pathname
CL-USER 2 > (type-of #p"D:/tfb-project/tmp/foo.bar")
pathname
--tim
Peter Seibel
> I personally think the real problem is the lack of the operation
> (STRING-FOR-HOST pathname host) => string which should be the
> inverse of PARSE-NAMESTRING with a non-NIL host argument.
[...]
> Its absence is not due to Zetalisp, it's due to the "subsetting" CL
> committee folk insisted on doing, wishing NAMESTRING were enough,
> and not seeing (exactly because most had only one file system) that
> it wasn't.]
What's the best place to read about the Symbolics pathname API? I have
a 4th ed. Chinenual; is that sufficient? Or is there more good stuff
that came later?
-Peter
--
Peter Seibel pe...@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Paul Foley
> Paul Foley <s...@below.invalid> writes:
>> AFAIK, no current CL implementation supports multiple physical hosts
> Symbolics' ANSI Common Lisp does. I have one running on the desk behind
> me. I even use it to debug portable code sometimes.
[...]
> I wish people would stop trying to universally quantify across
> implementations. Old implementations are allowed to stay and
> new ones to arrive. Trying to name the ones you know and use
> in your own experience denies (a) the past, (b) the future, and
> (c) the possibility of things today outside of your own experience.
I did say "as far as I know" -- and I was wrong, because I did know
about Symbolics; I just didn't think of it. I wasn't trying to
exclude anything.
>> (of different kinds; LispWorks on Windows has a host for each drive,
>> but they're all the same kind of thing), so of course all logical
>> pathname translations bottom out in a physical pathname on the single
>> supported physical host, and they all have the same syntax.
> I'm not sure I see your point here. Is there some specific action on
> someone's part advocated on the basis of this controversial claim you've
> made?
> Variant implementations are not to be beaten into the ground, they are
> to be permitted their right to exist. Our language was built around
> tolerance for deviation of a variety of kinds, and thank goodness it was.
Did you read the post I was replying to? You seem to think I'm
bashing LispWorks, or something. I'm not. Pascal asked to be pointed
to a CL implementation that had at least two different physical
pathname syntaxes; I just said that no implementation I know of has
two physical hosts at all, except LispWorks, and that the multiple
hosts supported by LispWorks all use the same syntax since they're all
for the same Windows filesystem.
Raffael Cavallaro
> james anderson <james.a...@setf.de> writes:
>
> > i had understood the discussion to pertain to pathname designators in lisp,
> > not in a unix shell.
>
> Physical pathnames in lisp are the same as used in a unix shell, when
> the lisp implementation is on unix. At least, it should.
>
> > >
> > >
> > > If I've understood what was being said, we would have had to write:
> > >
> > > naiad:Macintosh\ HD:bin:ls naiad:Macintosh\ HD:Users:pascal:thalassa/src/lisp
> > >
> > > Or some silly thing like that.
> > >
> >
> > you might want to take a look at mcl. people have been using it to do silly
> > things for about twenty years now.
I think there's a bit of talking at cross purposes here because Mac OS
X supports both the older, Mac OS Classic colon delimiter in Carbon
(MCL, a Carbon app, still uses the colon for pathnames), and the Unix
forward slash delimiter in the BSD subsystem (OpenMCL, which runs from
the unix command line and as a Cocoa app uses the forward slash for
pathnames). For example, the unix shell uses the forward slash, of
course, while AppleScript still uses the colon.
MCL
Welcome to Macintosh Common Lisp Version 5.0!
? (full-pathname (user-homedir-pathname))
#P"MacOSX:Applications:MCL 5.0:"
OpenMCL
Welcome to OpenMCL Version (Alpha: Darwin) 0.14-031018!
? (full-pathname (user-homedir-pathname))
#P"/Users/raffaelc/"
Kent M Pitman
> Kent M Pitman <pit...@nhplace.com> writes:
>
> > I personally think the real problem is the lack of the operation
> > (STRING-FOR-HOST pathname host) => string which should be the
> > inverse of PARSE-NAMESTRING with a non-NIL host argument.
>
> [...]
>
> > Its absence is not due to Zetalisp, it's due to the "subsetting" CL
> > committee folk insisted on doing, wishing NAMESTRING were enough,
> > and not seeing (exactly because most had only one file system) that
> > it wasn't.]
>
> What's the best place to read about the Symbolics pathname API? I have
> a 4th ed. Chinenual; is that sufficient? Or is there more good stuff
> that came later?
The chineuals (pronounced "SHEEN-you-ull", and so-named, for those who
don't know, because it said
"Lisp Machine
Manual"
but the words were wrapped around from back to front, so that on the
cover you mostly saw just:
"Lisp Ma|chine <-- this
Man|ual" <-- and this
)
were written in the early days at MIT when things were
small. The chineual documented the whole operating system, language,
UI, and other stuff. The thickest of them was probably about 3 inches
thick.
Symbolics at its largest had about 1000 people working for it,
although it was then diversified working on a variety of products and
had a complex manufacturing and sales operation. There was a core of
about 20 or 30 people working full time throughout all that time on
the operating system itself, with maybe 5-10 documenters and as many
QA people and for a while as many teachers. The Symbolics doc set in
its final form formed a set of documents about 2 feet across, like an
Encyclopedia, only (I thought) prettier. You can, from time to time,
catch people selling them, sometimes even on this newsgroup.
The chineuals are fun to have for historical reasons, but they don't
scratch the surface of what the Lisp Machine came to be.
Also, in the early days (like when chinenuals were the thing), everything
was Zetalisp and there was no internal/external symbol distinction.
So API was a strange notion, since really everything was accessible and
everyone had sources. (Open source is notorious for tempting people
to use things you hadn't intended...)
It wasn't until the transition from Old Flavors in Zetalisp, using
the (send x :string-for-host) notation to the New Flavors
(fs:string-for-host x) notation that we started using packages based
on CLTL1 and having an internal/external distinction, where the first
hint of "intended API" started to become visible. Though even then I'm
not sure it was as crisp as what you're looking for.
Someone might could get you a list of the FS package external symbols, I
guess. That might be a good start. (I'm away from home as I write this,
so can't just ask my Macivory to type that out...)
Tim Bradshaw
> You are, of course, trolling, but for the benefit of those who don't
> realize that you are: There is really a great deal of work being done
> on Linux filesystems above and beyond POSIX ACLs. Try Googling for any
> of the following terms:
> SELinux MAC
> Intermezzo
> ReiserFS
So, let's see: SELinux MAC is mandatory access controls. Like those
offered by, say, trusted Solaris and many systems before it. Well,
good to have, but hardly a step in the dark. ReiserFS is a
journalling filesystem with atomic properties & clever space
allocation. Like, say, VxFS. Again, it's good to have, but it's
hardly new technology. Intermezzo is a distributed filesystem, which
may actually be interesting (I'm not really familiar with other
distributed filesystems so I can't comment).
With the possible exception of Intermezzo, this is canonical Linux
software: decent (often very good) knock-offs of things that already
exist commercially. And this is the wave of creativity which has
change software for ever? I think not.
--tim
Pascal Bourguignon
raf...@mediaone.net (Raffael Cavallaro) writes:
> I think there's a bit of talking at cross purposes here because Mac OS
> X supports both the older, Mac OS Classic colon delimiter in Carbon
> (MCL, a Carbon app, still uses the colon for pathnames), and the Unix
> forward slash delimiter in the BSD subsystem (OpenMCL, which runs from
> the unix command line and as a Cocoa app uses the forward slash for
> pathnames). For example, the unix shell uses the forward slash, of
> course, while AppleScript still uses the colon.
Let's keep sane and just assume
that on MacOS all paths are written with colons
and on MacOSX all paths are written with slashes.
> MCL
>
> Welcome to Macintosh Common Lisp Version 5.0!
> ? (full-pathname (user-homedir-pathname))
> #P"MacOSX:Applications:MCL 5.0:"
>
>
> OpenMCL
>
> Welcome to OpenMCL Version (Alpha: Darwin) 0.14-031018!
> ? (full-pathname (user-homedir-pathname))
> #P"/Users/raffaelc/"
--
james anderson
Pascal Bourguignon wrote:
>
> Let's keep sane and just assume
> that on MacOS all paths are written with colons
> and on MacOSX all paths are written with slashes.
>
> > MCL
> >
> > Welcome to Macintosh Common Lisp Version 5.0!
> > ? (full-pathname (user-homedir-pathname))
> > #P"MacOSX:Applications:MCL 5.0:"
-------^^^^^^
Rob Warnock
+---------------
No, that's Perl. ;-}
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock
+---------------
| (b) Near-functional BSD sources were available circa 1990 and
| functional ones not much later (91 or 92?). So tell me, *why* did
| Linux reinvent it all? Maybe because he couldn't think of
| anything more interesting to do.
Well, let's see... He *might* have wanted to use BSD as a base,
but wasn't that right around the time of the AT&T lawsuit against
BSDI & UCB? Perhaps he got scared off.
And by the time the lawsuit was finally settled (mostly against AT&T),
Linux had already been written and had a fast-growing community.
Rayiner Hashem
project, there wasn't a good x86 version of BSD widely available.
386BSD wasn't released until nearly 1 year after the first release of
Linux. However, Linus has been quoted as saying it was because of the
AT&T lawsuit that he continued Linux beyond the initial stages.
Paolo Amoroso
> What's the best place to read about the Symbolics pathname API? I have
In case you are interested in the TI Explorers pathname facilities, a
good set of manuals is available at the Minicomputer Orphanage. Check
the relevant chapter of the Programming Concepts manual.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Pascal Bourguignon
> > Tim Bradshaw <t...@cley.com> wrote:
> > +---------------
> > | (b) Near-functional BSD sources were available circa 1990 and
> > | functional ones not much later (91 or 92?). So tell me, *why* did
> > | Linux reinvent it all? Maybe because he couldn't think of
> > | anything more interesting to do.
> > +---------------
> >
> > Well, let's see... He *might* have wanted to use BSD as a base,
> > but wasn't that right around the time of the AT&T lawsuit against
> > BSDI & UCB? Perhaps he got scared off.
> >
> > And by the time the lawsuit was finally settled (mostly against AT&T),
> > Linux had already been written and had a fast-growing community.
hel...@mindspring.com (Rayiner Hashem) writes:
> Actually, the reason was that, at the time Torvalds started the
> project, there wasn't a good x86 version of BSD widely available.
> 386BSD wasn't released until nearly 1 year after the first release of
> Linux. However, Linus has been quoted as saying it was because of the
> AT&T lawsuit that he continued Linux beyond the initial stages.
Indeed, my first FreeBSD Version 1.0 CD-ROM is dated December 1993.
It's very important to make the difference between Open Source and
Free Software!
Of course, anybody with a deep pocket could buy the sources of AT&T
unix or get BSD sources from Berkeley University and pay lawyers.
That would not have meant that they could do whatever they wanted with
"their" sources.
If Linus had proceeded like the FSF and requested to obtains signed
paper assigning the copyright to any line of code added to Linux to
him or a Linux Foundation, we would not have problems like SCO right
now.
Cor Gest
Begin of a quotation from a message written by mere mortal:
Pascal Bourguignon <sp...@thalassa.informatimago.com>:
> Of course, anybody with a deep pocket could buy the sources of AT&T
> unix or get BSD sources from Berkeley University and pay lawyers.
> That would not have meant that they could do whatever they wanted with
> "their" sources.
>
>
> If Linus had proceeded like the FSF and requested to obtains signed
> paper assigning the copyright to any line of code added to Linux to
> him or a Linux Foundation, we would not have problems like SCO right
> now.
But who do you sue ? when nobody _owns_ linux as an entity in a judicial sense,
apart from n*10^2 different people worldwide with a copyrigh-part to
a total of n*10^6 lines of code from an multitude of IP//law-sytems ?
It is (practically) impossible to put the cat back in the bag.
cor
--
The Worlds best understood IM-appliance...........Avtomat Kalashnikov AK-47
NO !! I Will NOT Fix Your Computer http://www.geekgrrrl.nl
(setq reply-to (concatenate 'string "Cor Gest " "<cor"'(#\@) "clsnet.nl>")
Coby Beck
> There is no worse tyranny than to force a man to
> pay for what he does not want merely because you
> think it would be good for him.
-- Robert Heinlein
With all due respect to Robert Heinlein, what a ridiculous statement.
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
Pascal Bourguignon
Cor Gest <c...@clsnet.nl> writes:
> Begin of a quotation from a message written by mere mortal:
> Pascal Bourguignon <sp...@thalassa.informatimago.com>:
>
> > Of course, anybody with a deep pocket could buy the sources of AT&T
> > unix or get BSD sources from Berkeley University and pay lawyers.
> > That would not have meant that they could do whatever they wanted with
> > "their" sources.
> >
> >
> > If Linus had proceeded like the FSF and requested to obtains signed
> > paper assigning the copyright to any line of code added to Linux to
> > him or a Linux Foundation, we would not have problems like SCO right
> > now.
>
> But who do you sue ?
SCO's lawyers have a response: the users.
> when nobody _owns_ linux as an entity in a judicial sense,
> apart from n*10^2 different people worldwide with a copyrigh-part to
> a total of n*10^6 lines of code from an multitude of IP//law-sytems ?
>
> It is (practically) impossible to put the cat back in the bag.
I don't know that is better (and I object to "unconditionnaly" assign
Copyright to a third party while I have no objections to the GPL for
example (which did not prevent me to have assigned copyright of some
sources contributed to some FSF project)).
Just that in this specific case, SCO could not have sued, because
there would have been SCO CEO's signature on file with the Linux
Foundation.
Pascal Bourguignon
> "Pascal Bourguignon" <sp...@thalassa.informatimago.com> wrote in message
> news:87u145o...@thalassa.informatimago.com...
>
> > There is no worse tyranny than to force a man to
> > pay for what he does not want merely because you
> > think it would be good for him.
> -- Robert Heinlein
>
> With all due respect to Robert Heinlein, what a ridiculous statement.
I assume you object to the "There is no worse tyranny" part. For some
of us, moral inconveniences are more hurting than physical ones. Some
even say: "Freedom or Death!".
Jan Rychter
Pascal> Pascal Costanza <cost...@web.de> writes:
[...]
>> This means that you cannot solve UI issues in a strictly
>> platform-independent way. (At least AFAIK.)
Pascal> But then there are more considerations. For example, my first
Pascal> PDA is a 64 MB RAM 400 MHz machine. I DO expect it to be able
Pascal> to multitask (and don't get it) and while I don't expect to
Pascal> move and resize windows on its 320x320 screen most problems
Pascal> come from applications that don't expect such a BIG real estate
Pascal> (and the increased resolution). Note that there are PDAs with
Pascal> 320x480 screen that come quite close to the 512x342 of the
Pascal> original Macintosh.
[...]
Tell me about it. I use a Sharp Zaurus SL-C760, which has a 640x480
screen. Most older applications written for the older Zaurus models do
not expect this screen resolution. What's worse, even though it is
really VGA resolution, you don't get VGA monitor screen size, which
means you really have to design carefully, taking DPI into account. You
don't want to paint tiny UI controls that no one can use.
Just to try to keep this thread a bit on-topic: I am dreaming of the day
when I'll be able to program my GUI applications on a PDA such as this
one using Common Lisp. Mind you, the hardware should be fully
sufficient: it's a 400MHz processor, 64MB of RAM, 128MB of built-in
flash plus SD expansion cards. I run xemacs on it, and I have tried
using CLISP, that someone compiled for it.
I am somehow convinced that a well-designed framework in CL could even
be more efficient memory-wise than the crazy C++ shared library world of
Qtopia on Linux (which is what the Sharp Zaurus PDAs use).
--J.
Rob Warnock
+---------------
| Actually, the reason was that, at the time Torvalds started the
| project, there wasn't a good x86 version of BSD widely available.
| 386BSD wasn't released until nearly 1 year after the first release of
| Linux.
Really?!? I was happily running 386bsd 0.1 for "real work" (albeit
only mail, news, etc.) in July 1992 (on a 33 MHz '486 with 16 MB RAM
and SCSI disk). When was Linux first used for production work by
random outsiders?
+---------------
| However, Linus has been quoted as saying it was because of the
| AT&T lawsuit that he continued Linux beyond the initial stages.
+---------------
Yeah, that pretty much confused the issue for everybody for a while.
Harald Hanche-Olsen
| There was a file system called Eunice that was layered on VAX VMS
| (I think),
Eunice was more than a file system. It was a unix emulation
environment (on top of VMS as you said). It was good enough to let
you compile and run (reasonably generic) C programs written for unix,
among other things.
| which if I recall gave the illusion of mixed-case filenames,
It would have to, in order to pretend to be unix.
| but by prefixing each lowercase letter with a "$" in the filesystem,
| so that what seemed to Lisp like "Foo" was really "F$O$O" or some
| such thing.
Or maybe it was the other way around, i.e., "$FOO". I don't recall
exactly, but it would make more sense given the lower case conventions
of the unix world.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Tim Bradshaw
> Well, let's see... He *might* have wanted to use BSD as a base,
> but wasn't that right around the time of the AT&T lawsuit against
> BSDI & UCB? Perhaps he got scared off.
The point I was trying to make is that it was obvious (to me at least
- perhaps I was wrong, but I never thought AT&T stood a serious
chance) in the ~1990 timeframe that there would soon be free BSD
codebase. Legacy applications which required Unix compatibility were
going to be able to run on that. The time was right to move forward:
write a new modern OS with new features. Tragically, that's not what
happened and we ended up with a (very good) Unix clone. I see this as
just a huge failure of imagination, which unfortunatly characterises
the free software movement which excels at producing very good copies
of already existing stuff, but with few exceptions (perl? arc) does
hardly anything new.
Similarly, before getting side tracked I was trying to argue that the
Unix filesystem is not (syntactically or semantically) the last word
in FS design, and it is a completely sensible thing to do for Lisp
systems to support multiple pathname syntaxes. I don't think the CL
pathname system is the last word *either* - in particular it's not
well enough specified, too restrictive, and has various other issues.
But it's a start, and saying that the Unix pathname syntax is all you
need is just stupid.
Here's an example where the Unix syntax is inadequate, and also,
incidentally, where the CL pathname system falls down. ClearCase
provides what is essentially a filesystem which supports serious
version control. ClearCase pathnames have a hairy version component
(so they are extensions of Unix pathnames) and a number of other
significant features which Unix pathnames don't support. The version
component is, in fact, more than the CL pathname system can deal with,
because it's generally a compound object specifying branch, tags &c
&c. Finally, you can specify a `view' to ClearCase which defines
which versions you get by default. I think the view would probably
equate to the pathname host, although that's not really correct.
--tim
David Golden
direction Hans Reiser outlined, then perhaps even many
Linux boxes will need much more than unix pathnames.
Yes, ReiserFS brings ACID transactions. But Reiser/namesys
also intend it to bring "paths" (selectors, anyway) like:
[subject/[illegal strike] to/elves from/santa document-type/RFC822
ultimatum]
Fred Gilham
> Indeed, my first FreeBSD Version 1.0 CD-ROM is dated December 1993.
But this is by no means the first freely-available BSD. i386 BSD came
first, and then there was the patchkit, then netbsd, then freebsd,
then openbsd.
In retrospect, it's actually kind of amazing what the inability to get
along with others can lead to. :-)
--
Fred Gilham gil...@csl.sri.com
Is, then, the loving cup so often filled
that we may toss a draught aside?....
-Jeff Iverson
Fred Gilham
Pascal Bourguignon <sp...@thalassa.informatimago.com> writes:
> "Coby Beck" <cb...@mercury.bc.ca> writes:
>
> > "Pascal Bourguignon" <sp...@thalassa.informatimago.com> wrote in message
> > news:87u145o...@thalassa.informatimago.com...
> >
> > > There is no worse tyranny than to force a man to
> > > pay for what he does not want merely because you
> > > think it would be good for him.
> > -- Robert Heinlein
> >
> > With all due respect to Robert Heinlein, what a ridiculous statement.
>
> I assume you object to the "There is no worse tyranny" part. For some
> of us, moral inconveniences are more hurting than physical ones. Some
> even say: "Freedom or Death!".
While generally finding myself in agreement with Pascal, I have to say
I'm with Coby here. I think I've read too much Solzhenitsyn or
something.
I definitely agree that what Heinlein describes *is* a species of
tyranny.
--
Fred Gilham gil...@csl.sri.com
...every candid Reader will easily understand my Discourse to be
intended only in Defence of *nominal* Christianity, the other having
been for some time wholly laid aside by general Consent, as utterly
inconsistent with all our present Schemes of Wealth and Power.
--- Jonathan Swift, "Against Abolishing Christianity"
Rahul Jain
> Finally, you can specify a `view' to ClearCase which defines
> which versions you get by default. I think the view would probably
> equate to the pathname host, although that's not really correct.
Sounds to me like it's more related to *default-pathname-defaults*
having a version specified, although, of course, it can't be implemented
as such using the current pathnames specification.
--
Rahul Jain
rj...@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain
>> > news:87u145o...@thalassa.informatimago.com...
>> >
>> > > There is no worse tyranny than to force a man to
>> > > pay for what he does not want merely because you
>> > > think it would be good for him.
>> > -- Robert Heinlein
Not that anyone asked, but my opinion is that forcing someone to do pay
for something they don't want forces them to work when they don't want
the benefits of that work. Forcing someone to work when they don't want
the benefits of that work is slavery. The fact that you justify it by
claiming that it's good for them just makes the perpetrator that much
more devious. Maybe my imagination is weak, but I can't think of much
worse tyranny than slavery osentsibly for the slave's good.
Tim Bradshaw
> Sounds to me like it's more related to *default-pathname-defaults*
> having a version specified, although, of course, it can't be implemented
> as such using the current pathnames specification.
I thought of that, but I think that (probably) a pathname should carry
around its view and not depend on the ambient value of a special
variable (although kicking it off from such a value would be
sensible). Views can have quite hairy things in them, so when merging
a pathname against another the version selection might change.
But may be that could all be integrated with sufficiently elaborated
versions.
--tim
Rahul Jain
> I thought of that, but I think that (probably) a pathname should carry
> around its view and not depend on the ambient value of a special
> variable (although kicking it off from such a value would be
> sensible). Views can have quite hairy things in them, so when merging
> a pathname against another the version selection might change.
Fair enough. I do not have the misfortune of ever having to use
ClearCase. :)
Christopher C. Stacy
Tim> ClearCase pathnames have a hairy version component (so they are
Tim> extensions of Unix pathnames) and a number of other significant
Tim> features which Unix pathnames don't support. The version
Tim> component is, in fact, more than the CL pathname system can deal
Tim> with, because it's generally a compound object specifying
Tim> branch, tags &c&c
Tim> Finally, you can specify a `view' to ClearCase which defines
Tim> which versions you get by default. I think the view would probably
Tim> equate to the pathname host, although that's not really correct.
Just because ClearCase calls something a "version" does not mean
that it would necessarily map to a Lisp pathname version component.
That part of the interface might be accomplished by using some other
pathname component, such as the directory, like you suggested the
"view" would be.
There are ClearCase operations that are outside the scope of the ANSI
Common Lisp pathname system. Perhaps PATHNAME-VERSION would be used
to indicate only part of the "version" information; maybe a standard
monotonically increasing instance number that (along with the host
and directory) corresponds to some ClearCase branch or view selection
criteria that is represented in the pathname or elsewhere in the
Lisp implementation's ClearCase interface.
After all, all that ClearCase stuff is being represented in the Unix
or Windows operating system pathnames, using various similar tricks,
such as the pathname device representing the view.
Also, sometimes (at least) the "file system" can be provide more
information about the "files" that these pathnames correspond to.
That's what file properties are for. (Oh, right. ANSI took
those out, too, sigh.)
Maybe extending PATHNAME-VERSION to allow other objects besides
integers and symbols would be a good idea, but I am not sure that
we have enough collective experience to know what would be better.
Certainly we do not have a sense of how much code would break.
Such an extension was not proposed in the relevent X3J13 cleanup
issue, which was authored by a developer from Symbolics.
Symbolics Genera has its own version control system,
which operated on top of the versioned file system.
PATHNAME objects had VC-BRANCH and VC-VERSION,
I don't know if ANSI allows new components like that.
Their semantics would necessarily be implementation dependant, since
we're talking about wildly differing notions of how files are stored.
In any event, files are only a low-level storage concept,
and more complex notions of how data might be accessed are
built on top of them. That's why version control systems,
sophisticated content-management systems, databases, and
data query and retrieval systems are built on top of them.
Pathnames and files are none of those things.
Tim Bradshaw
> There are ClearCase operations that are outside the scope of the ANSI
> Common Lisp pathname system. Perhaps PATHNAME-VERSION would be used
> to indicate only part of the "version" information; maybe a standard
> monotonically increasing instance number that (along with the host
> and directory) corresponds to some ClearCase branch or view selection
> criteria that is represented in the pathname or elsewhere in the
> Lisp implementation's ClearCase interface.
Oh, sorry, I've been confusing. I wasn't trying to suggest that the CC
pathname system could, or should, be wedged into the Lisp pathname
system. Rather, I was putting it forward as a system which was richer
than Unix pathname syntax really allows for, and which, incidentally,
is also richer than the current CL pathname system can easily and
naturally support, I think. It was meant as a counterexample to the
kind of `just represent everything as a Unix pathname' idiocy. There
are filesystems which have notions which are not easily supported by
the Unix filesystem, and I think the CC filesystem is one. It turns
out that the CL pathname system probably needs extending too (or
rather: being redesigned so it's user-extensible), which makes the
point even more strongly!
> After all, all that ClearCase stuff is being represented in the Unix
> or Windows operating system pathnames, using various similar tricks,
> such as the pathname device representing the view.
Yes, it is. but `being represented' at the Unix user-code level is
just `adding some special magic characters to the namestring which is
all the system lets you talk about', and then requiring a user-level
parser to extract some kind of structured object. I'm interested in
pathnames which are a bit richer than strings. (Presumably at the FS
implementation level in a typical Unix, there are more structured
objects, and I guess that the CC filesystem has its own classes of
objects at that level).
--tim