[portable pathname formats] visible hash tables

["Robert W. Kerns" <RWK@AI.AI.MIT.EDU>]

    Date: Tue, 17 May 88 16:22:13 PDT
    From: Jon L White <edsel!jonl at labrea.stanford.edu>
    To:   Skef.Wholey at SPICE.CS.CMU.EDU
    cc:   common-lisp at sail.stanford.edu
    Re:   [portable pathname formats] visible hash tables 

    re: Well, just today I heard a user ask a CMU-CL implementor
        about having Lucid CL on a Sun talk to CMU-CL on an RT.  Among other
        things, these two Lisps share the same network file system, and so
        passing pathnames back and forth is a sensible thing...)

    Symbolics has something like"logical pathnames"; I'm not familiar enough with
    it to comment on whether or not that approach is satisfactory.  Are you?

I am.  Logical pathnames solve a different problem: taking a program
which contains pathnames and porting it to a different site with different
machines and directory layouts.

The problem here is rather different; a problem of naming.  What is needed
is a syntax that includes an (optional) host name, and a PATHNAME-HOST
slot in pathnames.  As Symbolics does, and as DEC does with their pathnames
with DECNET.  (TI and LMI, too).  (I don't know what DEC's CL does with this).

The syntax of the rest of the pathname is determined by the foreign
host.  In Symbolics' case, since it needs to understand the syntax
(in order to do things like cross-host defaulting, etc.), it knows how
to parse each hosts' syntax locally.  In DEC's case, they leave the parsing
to the remote system and pass it through uninterpreted.  (Symbolics does the
same when the foreign host is of some type it never heard of, which is pretty
rare since it's heard of most things you or I would use, and is not too hard
to extend).

Logical pathnames are more useful in a networked environment, of course.
Symbolics' logical pathnames even allow you to split one logical host over
several physical hosts of various types.