re: PATHNAME-PRINT-READ, v1

[Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>]

I agree with your sentiments regarding multiple file systems.  We spent a lot
of time thinking about the problems involved in dealing with such situations,
and I don't know that we really got very far in solving them.  To some extent
we've punted, since we are currently in a "single file system" environment.
That's changing though, and we're going to have to face up to the situation.

While I wasn't persuaded by the arguments for #H for printing hash-tables, I
think they bear more weight in the case of pathnames.  I could easily be
persuaded to support printing pathnames in some standard format (though not
necessarily #P -- I agree with GSB (1/5/89) and Dan Pierson (1/6/89) that we
should be careful about chewing up # reader macros), if it could be specified
in such a way that multiple file system problems were at least solvable
(preferably solved, but that seems to be asking too much). 

BTW, I don't think a Symbolics pathname of #P"host:asdf" is equivelent to
#.(parse-namestring "asdf" "host"), since the former contains a manifest host,
while the latter might not (depending on how "host" parses the string "asdf").
On rereading the top of CLtL p.415 though (manifest host must match explicit
parsing host), maybe the "right" way to print the latter is really

  #.(parse-namestring "asdf" nil #.(parse-namestring <string> "host"))

  <string> := namestring which specifies only the host "host", in the syntax
              used by the host "host" (got that).

Bletch.

Fortunately, most of the time this can be collapsed to the former rendering in
one way or another.  The case where you can't seems pretty pathological (parse
a string according to some host's parsing conventions, but it contains a
manifest host which is not only not the host used for parsing, but parses
pathnames differently from the host used for parsing).

kab
-------