pathnames

[Luca Pisati]

  Luca Pisati [pisati@nichimen.com] sez:
  ;; Probably most of pathname design in CL is good, but I do not fear
  ;; to have to change in order to provide more independence from
  ;; platform issues.
  [ ... ]
  ;; One thing was far better on LispM than in ANSI CL was the total
  ;; flexibility of pathnames. They where well defined structures,
  
  I'm afraid you have an advantage over me here - I've never had the
  pleasure of using a LispM. I'm in agreement here - I'm not averse to
  reworking them, I just think that we shouldn't go re-engineering
  pathnames. 

Just as a note.  I'm not a fan of LispM to such an extent.
I do not think that cloning an existing LispM is my goal.
And because of this, I'm just trying to point out some
of the advantages LispM pathname systems have over
ANSI-CL, and which problems ANSI-CL pathnames
inherited from LispM.  After this, most of the topic
is now coming to small details (and I'm sorry I'm
contibuting to thread over details).

  Make them more easily extensible to deal with new
  abstractions, to allow discontigous disks to look like one logical
  disk, make any program than knows how to talk pathnames be able to
  talk a new netwrok protocol by transparently extending the underlying
  objects.
  
  Now, building a new abstraction to deal with an OS which has no files,
  only persistent objects - that could be done from scratch.
  
  ;; and extending them was incredibly trivial.  I actually did it a
  
  Amen. Everything should be extensible.
    
  ;; I fully agree with these.  The only point is that ANSI-CL pathnames
  ;; have probably to be twisted just a little bit, in order to do a
  ;; better and seamless merging.
  
  Again, I think we're in agreement here.
  
  - Adam
  
  --  
  Adam Alpern <alpern@brightware.com>
  http://www.brightware.com/~alpern/