[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


modifications were made, as follows:

  [This information may be explicitly represented as an additional slot, or
  computed on demand using a lookup table, as the implementor prefers.]

I'm not sure what your bracketed comment means, but the
important example is
where of course the string is implementation-dependent.  That is,
PATHNAME-CANONICAL-TYPE must produce a canonical type even when the
pathname was not constructed from a canonical type, but instead came
 from user typein, the TRUENAME function, the DIRECTORY function,
or some similar source, when the pathname's type is one that a
canonical type maps into.

It would be good to have a facility for users (in addition to
implementations) to extend the set of canonical type names, since users
may well have their own types of files.  In Genera this is named
FS:DEFINE-CANONICAL-TYPE.  The difficulty is that in any system that
supports multiple file systems, FS:DEFINE-CANONICAL-TYPE has to be
complex enough to allow specification of separate mappings for each file
system, which requires a way to name file system types, but maybe that
would be too complex for some people's taste.

  Define the following standard types:
	:LISP		``Lisp'' (source) file
	:BIN		``Compiled Lisp'' (object) file
  Permit implementations to extend the set of canonical type names.

All the comments I saw were opposed to :BIN, and I oppose it too.  In
fact I am opposed to any standardized name for this canonical type,
primarily because this ought to vary based on various
implementation-dependent parameters.  For example, in Genera it varies
depending on the processor type.  I believe that Common Lisp should
standardize only the name of a variable whose value is the canonical
type for the output of COMPILE-FILE.  In Genera this variable is named
SI:*DEFAULT-BINARY-FILE-TYPE*, a really lousy name.  How about