Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Thu, 21 Jul 88 23:01:09 BST
    From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>

    ... And I still have difficulty imagining interesting things portable
    programs can do without such a convention (apart from the things
    pathnames already provide, such as parsing).  Or, perhaps I should say
    I have difficulty imagining interesting things made possible by the
    canonical case proposal.  I can easily see the virtues of canonical
    types.  But the gain from having the case made magically right seems
    small. ...

I'd wager that there is a sizable number of TOPS-20 users out there who
don't know that the TOPS-20 file system admits lowercase names. The only
trouble is that to refer to such a filename in any of the normal TOPS-20
programs, you have to quote every character with Control-V.

Sure, you can say that (MAKE-PATHNAME :TYPE "foo" :VERSION "lisp") should
just create a file called "foo.lisp" on Unix and "foo.lisp" on TOPS-20 and
that should be fine for "portable" programs, but it's not because you have
to tell Emacs
 c-X c-F c-V f c-V o c-V o . c-V l c-V i c-V s c-V p
every time you want to edit the file. This is very unnatural even for people
who know it's what must be done. But for people who don't know it must be
done, they just wonder why "foo.lisp" shows up in their directory listing
but doesn't appear to be something they can edit or delete from outside of
Lisp!

The value you get from having canonical case is that files get created in
a natural way on any operating system.

It also turns out that this just makes file merging a lot simpler.
Consider an operation I do a lot on a day-to-day basis, which takes
advantage of the canonical type and canonical case issues:

 Command: Copy File (from) MYUNIX:/foo/bar/zap.l (to) MY20:
 Copying MYUNIX:/foo/bar/zap.l to MY20:<FOO.BAR>ZAP.LSP.0

rather than:

 Copying MYUNIX:/foo/bar/zap.l to MY20:<FOO.BAR>â??Vzâ??Vaâ??Vp.â??Vl.0

which we might have if neither of these proposals passed.

Sure, you can say that the Copy File command could go to massively more
work using system-dependent knowledge to do all the case foolery to get
machine-to-machine copying correct, but the fact of the matter is that
if all this stuff were defined correctly, you could write COPY-FILE in
nearly portable code (I say nearly only because I'm glossing byte-size
issues, an orthogonal problem):

 (WITH-OPEN-FILE (FROM-STREAM FROM :DIRECTION :INPUT)
   (WITH-OPEN-FILE (TO-STREAM (MERGE-PATHNAMES TO FROM)
			      :DIRECTION :OUTPUT)
     (STREAM-COPY-UNTIL-EOF FROM-STREAM TO-STREAM)))

and everything else takes care of itself. You could also argue that the
hair belongs in MERGE-PATHNAMES but why make work for yourself? There
only needs to be hair at all if you can't get agreement on some trivial
issues, such as those on the floor. If we can just agree on these
details, then no programs will need to have any hair -- things will
just work out.