[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: PATHNAME-SYSTEM-TYPE (version 1)
- To: sandra (Sandra J Loosemore) <@cs.utah.edu:sandra@defun>, "David A. Moon" <Moon@stony-brook.scrc.symbolics.com>
- Subject: Re: Issue: PATHNAME-SYSTEM-TYPE (version 1)
- From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
- Date: Mon, 29 May 89 21:00:15 BST
- Cc: CL-Cleanup@sail.stanford.edu, gray%dsg.csc.ti.com@NSFnet-Relay.AC.UK
> > Date: Thu, 25 May 89 16:55 EDT
> > From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> >
> > Since you're the one who says that pathname manipulating programs are
> > best written by getting namestrings and doing string processing on
> > them, can you tell me how your programs know what syntax to expect
> > in the namestrings?
>
> I've never said anything like that and I think it's a crummy idea
> anyway. What I *have* said is that the only pathname operations that
> a portable program can expect to do that make sense on all file
> systems are:
The only use Sandra gives for _pathnames_ (as opposed to strings)
that's at all interesting is the ability to merge pathnames. But,
of course, that too could be done with strings.
I have had a lot of difficulty understanding how pathnames are
supposed to be used in portable ways. When I've thought I've
understood an issue, I often find my explanation is almost the
opposite of one later given by, say, KMP. Nonetheless, I am
sure there are useful things that can be done with pathnames,
if only because the Symbolics folk (who are not idiots) keep
saying so.
But even if there are no completely portable uses of pathnames,
I absolutely reject the argument that anything that is not
completely portable should be eliminated from the language.
I am also unhappy with the suggestion that pathnames might
be allowed to exist nut without any MAKE-PATHNAME that constructs
them.