The feel of a LispM/List of running machines

[Luca Pisati]

  >> >WHY does unix still have no version
  >> >numbers?
  >> 
  >> Emacs has them, and emacs runs on Unix.
  >
  >Not at all.  Under Unix Emacs is simulating a versioning number.
  >Which means that the newest file has NO number.
  >
  >On the Symbolics versioning is PART of the OS, and the newest file
  >is simply the highest number.
  
  You missed the point.

  The point is, that for people who would like to retain UNIX
  compatibility, an arbitrarily advanced or complex Lisp file system can
  be implemented on top of a UNIX file system. That doesn't mean that
  the facility has to be any less seamless or any less "part of the
  LispOS".

Maybe. We have and sell a graphics system running on ACL and
cross-platform on IRIX and Windows NT, and one of the non easy things
is to share code to deal with pathnames.  One problem is that ANSI-CL
is trying to implement pathnames as a virtual file-system, and that
creates a lot of troubles (e.g. extension is a slot in a pathname,
but the concept does not exist in Unix). I'm not that sure that it is
a trivial problem to have a generic interface to many different
file-systems. Just consider for example the problem of "what
type is this file". On the SYmbolics they had extensions, and
extensions coupled with canonical-types were used to derive the
type of a file (and of course you couldn't use different extensions).
On Windos it is pretty much the same, on IRIX (SGI), the desktop
directory browser use an euristic of extensions + permission flags
+ magic numbers parsed from the file itself. On MacOs every file
consists of a data fork + a resource fork, in which, apart a lot of
other stuff, the type and creator of the file is effectively stored.
Just to achieve proper "launch" behaviour, unix is probably one
of the worst file-systems around.

Sorry for the long reply, but, as you can see, I'm not that much
in love with the structure of unix files ...

  Of course a native Lisp file system will of course be faster and more
  optimised in it's implementation. That's fine, I'd like one of those
  too :-)