Issue PATHNAME-PRINT-READ, v1

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

Yes, hosting is an issue that I deliberately glossed in the proposal.
Let me say a few words about that and other issues that have been raised.

 - I think #P is better than #. for the same reasons that Touretzky
   proposed #H instead of relying on #. . That is, because most Lisp
   data can be understood by engines considerably less complex than
   Lisp itself. Lists, numbers, etc. are parseable and manipulable
   [are those really words? I say them a lot but they look funny 
   written down..] by simpler programs which do not contain EVAL.
   Using #. makes a large barrier to such programs in manipulating
   any data involving pathnames, which a priori should not be an
   opaque concept to non-Lisp programs.

 - The issue of hosts is more severe in a multi-file-system 
   environment than many CL implementors working in single-file-system
   environments may realize. At Symbolics, the decision was made a
   long time ago to use what's called the `host colon' convention.
   Basically, it says that the first `:' in a filename is -always-
   the separator of the host from other host-specific syntax. To
   avoid ambiguity, we simply define that you cannot have a 
   namestring with a device specifier (or whatever other host-specific
   thing a `:' may mean) without having a host specifier. So, if my
   default host is a Tops-20 named Hydrogen, I can write "<FOO>" or
   "H:<FOO>" to mean "<FOO>" on Hydrogen, but if there is a device
   "H" on Hydrogen, I must write either "H:H:<FOO>" 
   (to be context-independent) or ":H:<FOO>" (if I know that H is
   the default and I want to get past the `host colon'. Our
   NAMESTRING and PARSE-NAMESTRING obey these same conventions.
   So Symbolics pathnames print as #P"host:asdf" (to use your example
   above) without ambiguity. But I agree that without such a convention,
   there are still some rough edges. To make things work for external
   interfaces, though, pathnames support a :string-for-host message
   which gives you the string the file system wants to see.

   I have not proposed the Symbolics solution (which was a major
   changeover at the time it was introduced) even though I think it's
   the right thing (and has solved a lot of major problems) mostly 
   because I've seen serious resistance [eg, in issue PATHNAME-COMPONENT-CASE]
   to solving issues of multiple file systems. My impression is that
   enough people either believe that there is only one file system in
   the world or only one that they'll ever have to deal with or
   or at least only one that they'll have to deal with in any given
   running Lisp that they feel comfortable just sweeping these issues
   under the rug. I think that's very sad, and I think they're making
   a big mistake, but there's only so much I can do. Either someone
   else with multiple-file-system experience needs to stand up and
   help with this problem, or someone from the single-file-system
   world needs to our community a vote of confidence that we're not
   pushing these things on people gratuitously, or else people should
   just hang it up and expect to get screwed by cross-host problems
   such as the very real one you allude to.