[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[portable pathname formats] visible hash tables
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
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.