issue TRUENAME-SYNTAX-ONLY

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

    Date: Mon, 12 Sep 88 15:23:28 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

TRUENAME-SYNTAX-ONLY:ADD seems generally reasonable, however I have a
few comments to offer.  I think the proposal needs to be amended a bit.

    TRUENAME [with the :SYNTAX-ONLY option] applies any
    file-name translations performed by the file system and returns the
    "true name" of the specified file as a pathname.

Should it be left this vague, and specifically defined to be
implementation-dependent, or should some axioms that it must satisfy be
listed?  For example, should TRUENAME with and without the :SYNTAX-ONLY
option be required to return the same answer in the case when the latter
does not signal an error?  I suspect it may have to be vague (see below).

    (3) Clarify that coercion of a stream to a pathname (either implicitly
    or by a call to the function PATHNAME) returns a pathname representing
    the "true name" of the file.

This directly contradicts the example at the top of CLtL p.414.  I think
you should just remove this point.

    (4) Clarify that file-name translation on pathnames is not performed
    under any other circumstances except those listed above.

I can't figure out what this means operationally, but I suspect that if
I could figure it out, I would disagree with it.  I suggest removing this
point, unless you had something specific in mind, in which case I suggest
rewording this point.

What does (TRUENAME <stream> :SYNTAX-ONLY T) mean?

    Cost to implementors:

    Minor.  VMS provides an RMS system call ....

This overlooks the case of implementations that access VMS files via a
network file protocol.  The cost to implementors might be near infinite if
the particular network file protocol they are using does not provide any
way to perform this operation.  This suggests that the definition of the
:SYNTAX-ONLY option to TRUENAME should be left sufficiently vague that
an implementation that always returned its first argument would be valid.
A lot of the Common Lisp file system interface has to be like that.

    However, it
    would also be reasonable to restrict checking for syntax errors to the
    same places that file name translation is applied.

It would be at least as reasonable to argue that checking for syntax
errors is properly done during file name parsing (i.e. conversion from a
string to a pathname object), as with all other Common Lisp syntax.
Perhaps it would be better not to raise that issue in this proposal.