[ANSI] MAKE-PATHNAME Merging

[Howard R. Stearns]

[This doesn't fit the established categories, but I guess I see no reason
we can't also deal with questions of the ANSI spec as it stands. -BWM]

I have an extensive set of questions regarding the ANSI spec.
Is this the right place?
Is anyone out there?

Here's the first of a series of questions dealing with pathnames. If
there's anything I can do to improve the format of questions, let me
know.
-------------------------------------------------
MAKE-PATHNAME MERGING:
----------------------

ISSUES:
I. When should MAKE-PATHNAME merge components with the :DEFAULTS?
II. When merging is performed, how shall it be done?
III. Is make-pathname required to signal file-error when the
resulting pathname is illegal?

SUMMARY (Proposed - i.e. is the following interpretation correct):

MAKE-PATHNAME creates a pathname where the value of each component is
as specified by the corresponding keyword argument, if present. The
result is then merged as though by:

(MERGE-PATHNAMES pathname-created-from-arguments
DEFAULTS-argument-to-MAKE-PATHNAME)

However, where MERGE-PATHNAMES refers to whether or not its first
argument has a "supplied" or "explicitly supplied" component, the
corresponding case in MAKE-PATHNAME is when the component is actually
named as an argument -- regardless of whether the value is NIL.

MAKE-PATHNAME (and MERGE-PATHNAMES and PARSE-NAMESTRING) might create
pathnames which do not conform to the requirements of a certain class
of pathnames (such as logical pathnames). It is
implementation-dependent whether such violations are caught at the
time the pathname is created, or when accessed for namestring, file
system access, or component access.

EXPOSITION:

I. When is merging performed?

The dictionary specification for MAKE-PATHNAME (p. 19-17 in my copy of
the spec)
says:

After the components supplied explicitly by host, device,
directory, name type, and version are filled in, the merging rules
used by merge-pathnames are used to fill in any unsupplied
components from the defaults supplied by defaults.

My reading of this is that any component who's keyword argument is
supplied will not be merged -- even if it is supplied with a value of
NIL.

Example:
(make-pathname
:host nil
:device nil
:directory '(:relative "FOO")
:name nil
:type nil
:version nil
:defaults "sys:site;file.lisp.9")
=> #S(pathname :host nil :device nil :directory (:relative "FOO")
:name nil :type nil :version nil)

#+and-not
#S(logical-pathname :host "SYS" :device :UNSPECIFIC
:directory (:absolute "SITE" "FOO")
:name "FILE" :type "LISP" :version 9)

Some implementations that I have looked at (KCL based) use the
component values from :DEFAULTS for any NIL value, regardless of
whether they were explicitly supplied. (Interestingly, only CLISP
tries to "properly" merge :relative directories.)

II. When merging is performed, how shall it be done?

Is :NEWEST used as the ultimate default for version? Is this ultimate
default used when :VERSION was explicitly given as NIL?

Consider:

(pathname-version (make-pathname :name nil :defaults "foo.lisp.9"))
=> :newest ; :name was explicitly specified.
(pathname-version (make-pathname :version nil))
=> nil ; No merging, so no ultimate default merging.
(pathname-version (make-pathname :defaults (make-pathname :version
nil)))
=> :newest ; Merged, but merge left component unspecified, so
; use ultimate default.

III. Must MAKE-PATHNAME signal FILE-ERROR for invalid pathnames?

Consider:
(make-pathname :host "SYS" :device nil)

The dictionary spec for MAKE-PATHNAME (p. 19-17) says:

The resulting pathname is a logical pathname if and only its host
component is a logical host or string that names a defined logical
host.

And "The Device part of a Logical Pathname Namestring" (Section
19.3.1.1.2, p. 19-13 says:

... the device component of a logical pathname is always
:unspecific.
---
Submissions to: lisp-st...@cs.rochester.edu
Metamail (not for publication) to: lisp-standa...@cs.rochester.edu

An archive is maintained on ftp.cs.rochester.edu:/pub/archives/lisp-standards/
also accessible via the ALU home page:
http://www.cs.rochester.edu/u/miller/alu.html
Code submissions to: ftp.cs.rochester.edu:/incoming/

Please read the README files in those directories for directions.