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


I like your analysis. My argument is that the first paragraph of (1) is the
"most important", and is the only one that I think can be solved. While we
can make some requirements on lisp system's naming conventions, e.g., that
the naming convention that distinguishes a Lisp source and compiled Lisp
must affect only the type field, we can't require that of other
applications. Since your "assumptions" are often false ("all naming
conventions affect only the type field", "a given file system always uses
the same actual type for a given class of file"), a design which presumes
they are true are not good canditates for the standard. 
Similarly, there are numerous file systems where there is no good canonical
mapping from pathname-type to actual knowledge of the kind of file, and so
the prerequesites are not satisifed for being able to do recognition and
translation based merely on pathname-type. (I'm thinking of the Macintosh,
where the actual file type is frequently encoded not in the pathname but
rather in the 'creator' and 'type' fields, and DOS, where the three
character limit means that the same pathname-type is frequently used for
different interpretations by different applications, and some Xerox
systems, where the actual file type is encoded by a 16-bit file attribute,

I don't think it is merely a matter of policy whether Common Lisp should
support all three features; I think it is also a matter of feasibility. If
supporting the features is in fact impossible in many file systems, we
shouldn't require them to be supported. Since Lisp implementors have
control over the file types used by their compiler, we can require
canonical values for make-pathname, however.