Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Fri, 22 Jul 88 15:30 EDT
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

	Date: Fri, 22 Jul 88 13:25 EDT
	From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    
	    Date: Fri, 22 Jul 88 11:04:45 MDT
	    From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
    
	    Under the "Current Practice" section, you might add ...
    
	    (defvar *binary-file-type* ...)
    
    Good point. You're not the only one.

	Looks like a good argument for standardization, since I think some
	of these are wrong, and it would probably take half a week to test
	them all.

    Just to clarify, I think Moon meant (he can correct me if I'm wrong)
    that this is an argument for canonical types, not an argument for
    a *binary-file-type* variable, since the same implementation may have
    to talk to multiple file systems, and since different extensions may
    be used in different file systems, and hence a single extension may
    not be appropriate for every file system.

Well, what I meant was that some of the file types in Sandra's list are
(I suspect) not the ones that the compiler in those systems actually uses.
I wasn't thinking deeper than that.

Now, getting into details beyond what I meant, there is an argument for
canonical types because a single implementation may use multiple file
systems with different file types, and hence no single string per
implementation can work.  True.  That's the issue within a single
implementation.  There is also the multiple implementation issue: can
all implementations agree on a single canonical type that is used as the
output of the compiler, or should there be a standardized variable whose
value is that canonical type?  One might think that everyone could agree
on a single canonical type for compiler output, but in fact not all
Symbolics implementations use the same canonical type, so even within a
single vendor there is disagreement.  One might think this is stupid,
but in fact Symbolics has multiple types of bin files, all(?; more than
one anyway) of which are understood by some implementations, so it's
unclear how to squeeze that into a single universal canonical type.

I suppose the people who aren't used to thinking about multiple file
systems at the same time are thoroughly confused at this point.  Let me
recap:

In increasing order of abstraction:

KMP's pathname component case proposal abstracts the notion of "this
alphabetic case is the standard one, and this other case is the unusual
one".  Abstracting this instead of just using strings verbatim is useful
because file systems disagree on which case is standard (Symbolics and
Unix use lower case; all major computer vendors (IBM, DEC, CDC, etc.)
use upper case.  [If anyone responds with an argument about who is major
and who is minor, I will jump up and down and scream.  That's not the
point.]).

Canonical types abstract the notion of "such and such pathname-type
field means such and such semantic content in the file".  Abstracting this
instead of just using strings is useful because we might be dealing
with multiple file systems, each of which already has its own convention
for what the string should be.

*binary-file-type* (si:*default-binary-file-type* in Genera) abstracts
the notion of "this canonical type is the one the compiler outputs."
Abstracting this instead of just picking a standard name for this
canonical type is useful because there might be several different semantic
file types that could potentially be the output of the compiler.

Whether anyone cares about these abstractions depends, obviously, on
whether the programs they write deal with these concepts and need to
be portable across file systems and/or across implementations.