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

Issue: PATHNAME-CANONICAL-TYPE (Version 1)



Issue:          PATHNAME-CANONICAL-TYPE
References:     MAKE-PATHNAME (p416)
Category:       ADDITION
Edit history:   07-Jul-88, Version 1 by Pitman
Status:	        For Internal Discussion
Related-Issues: PATHNAME-COMPONENT-CASE

Problem Description:

  The pathame-type of ``Lisp'' and ``Compiled Lisp'' files vary widely from
  implementation to implementation.

  "LSP" is common on Vax VMS. "lisp" is generally used for the Symbolics
  file system. "l" and "lisp" are common on Unix. Some Lisp implementations
  use customized extensions such as "cl" or even "jcl" (eg, for "Joe's CL").

  It would be useful to probe the existence of either a source or a binary
  file, but that cannot currently be done portably. Furthermore, it would be
  useful to create certain standard kinds of files in a system-independent
  fashion.

  A common desire, for example, is to do
    (DEFUN FILE-NEEDS-TO-BE-COMPILED (FILE)
      (LET ((SOURCE (PROBE-FILE
		      (MERGE-PATHNAMES FILE (MAKE-PATHNAME :TYPE ???))))
	    (BINARY (PROBE-FILE
		      (MERGE-PATHNAMES FILE (MAKE-PATHNAME :TYPE ???)))))
        ... (FILE-WRITE-DATE SOURCE) ... (FILE-WRITE-DATE BINARY) ...))
  The problem is that there's nothing portable to put in the ??? positions.

  Indeed, depending on the host (ie, file system) of the pathname, the
  type might need to differ even in the same Lisp implementation. For example,
  Symbolics Genera stores its source files in names like "foo.l" on Unix,
  "FOO.LSP" on VMS, etc.

Proposal (PATHNAME-CANONICAL-TYPE:NEW-CONCEPT):

  In addition to the normal strings and keywords currently allowed as fillers
  of the TYPE field of a pathname, allow other keywords which designate
  ``canonical types''. 

  A canonical type is translated to a real type by MAKE-PATHNAME so that the
  (PATHNAME-TYPE (MAKE-PATHNAME :TYPE canonical-type)) is a string.

  Introduce a new function PATHNAME-CANONICAL-TYPE which returns the canonical
  type of an argument pathname, or the type if there is no canonical type.
  For example,
    (PATHNAME-CANONICAL-TYPE (MAKE-PATHNAME :TYPE :LISP)) => :LISP
  [This information may be explicitly represented as an additional slot, or
  computed on demand using a lookup table, as the implementor prefers.]

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

Test Case:

  (PATHNAME-TYPE (MAKE-PATHNAME :TYPE :LISP))
   => "LSP" 	    ;Typically, on VMS
   => "l" or "lisp" ;Typically, on Unix
   => "L" or "LISP" ;Typically, on Unix 
		    ; (assuming PATHNAME-COMPONENT-CASE:CANONICALIZE adopted)
   ..etc.

  (PATHNAME-TYPE (MAKE-PATHNAME :TYPE :BIN))
   => "FAS" 	    ;eg, VAXLISP
   => "BIN"	    ;eg, Symbolics file system
   ...etc.

  (PATHNAME-CANONICAL-TYPE (MAKE-PATHNAME :TYPE :LISP)) => :LISP

  (PATHNAME-CANONICAL-TYPE (MAKE-PATHNAME :TYPE "LSP"))
   => :LISP	    ;eg, VAXLISP
   => "LSP"	    ;eg, Unix

Rationale:

  This is a useful subset of the functionality already available in
  at least one implementation.

Current Practice:

  Symbolics Genera implements this proposal.

Cost to Implementors:

  The cost of implementing these proposed features is very slightly.

  MAKE-PATHNAME would have to change to coerce its :TYPE argument in implementations
  where it does not do so already. PATHNAME-CANONICAL-TYPE can be implemented as a
  fairly straightforward lookup.

Cost to Users:

  None. This change is upward compatible.

Cost of Non-Adoption:

  It would continue to be hard to portably name files when their types
  differed from file system to file system.

Benefits:

  The cost of non-adoption would be avoided.

Aesthetics:

  Some programs would be able to abstract away from the particulars of the host
  file system entirely. Some people believe this would be a definite improvement
  in aesthetics.

Discussion:

  Note that different Lisp implementations which share the same file system,
  need not and perhaps should not agree on the same type string for the
  canonical type :BIN. That is, if I store source files on VAX VMS and compile
  them both for use under Symbolics Genera and VAXLISP, then it is both
  appropriate and useful that VAXLISP :BIN files be named "something.FAS"
  and Genera :BIN files be named "something.BIN" since then they wouldn't
  clobber each other.

  Pitman supports PATHNAME-CANONICAL-TYPE:NEW-CONCEPT.