Re: issue TRUENAME-SYNTAX-ONLY

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

    Date: Tue, 13 Sep 88 10:14:47 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    > Date: Mon, 12 Sep 88 21:12 EDT
    > From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    > 
    >     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).

    The language in CLtL is already vague, but as far as I know nobody has
    been complaining about it.  At least for VMS, I'd say that TRUENAME
    shouldn't have to return the same answer in both cases; the reason is
    that if you don't supply an explicit version number in the input
    pathname and you tell TRUENAME to match an existing file, it ought to
    fill in the version number for that file; but if you're only checking
    syntax it doesn't have any way of knowing what the version number
    should be.

I see.  Okay, let's not try axioms.  Now that I read it again, your
description of :SYNTAX-ONLY can't be right, though.  It refers to
"the specified file" but you aren't specifying any particular file.
Perhaps this can only be defined in terms of a VAX/VMS example.
Or perhaps it can be defined by saying that where file name components
are missing or wild or :NEWEST or :OLDEST, the :SYNTAX-ONLY option
tells you what's common to the truenames of all possible files with
all possible values for those components, whereas without :SYNTAX-ONLY
you specify a single specific file (after merging with a default)
and get just the truename of that exact file.  In fact what I just
said won't work in file systems with links, nor in those with complex
pattern-matching translation mechanisms (ITS has both, for example).
Perhaps you can come up with a better description of what :SYNTAX-ONLY
does?  I appear to have struck out.

    >     (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.

    Sorry, "clarify" was the wrong word here.  Except for the example you
    cite, CLtL doesn't explicitly address the issue of what coercing a
    stream to a pathname really does.  The idea is, that since OPEN must
    perform the equivalent of TRUENAME anyway, it can just as well create
    a stream that remembers the "true name" of the file as the pathname
    that was passed to OPEN.  As I recall, VaxLisp already behaves as
    proposed.  However, if people would prefer it that way, I could change
    this item to leave this behavior explicitly vague.

You're proposing that TRUENAME of a stream and PATHNAME of a stream behave
identically.  I think CLtL means for PATHNAME of a stream to return the
argument that was given to OPEN (after merging with the default).  I'm a
little surprised the Cleanup group haven't addressed this already.

    >     (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 I had in mind was that none of the zillion other pathname
    functions (which I was too lazy to list) would be allowed to do file
    name translation; nor would coercing a string to a pathname.  For
    example, (pathname-device "foo:bar.baz") on VMS would always return
    "foo", even if it's defined as a logical name.

I agree with that, but I think it can only be said explicitly, not by
implication from "any other circumstances."  For example, does "any other
circumstances" include all implementation extensions and all user-written code?

    >     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.

    That's a good point -- I'd forgotten about networking from non-VMS
    hosts.  However, if an implementation doesn't expand logical names
    fully when requested to do so, users are going to run into the same
    kind of strange behavior (i.e., within MERGE-PATHNAMES) that prompted
    me to bring this up in the first place.  

Yes, many network file access protocols are very poorly designed.  I don't
think X3J13 is going to fix that.

					     I don't see much point in
    adding this functionality to the language unless the spec is tight
    enough to ensure that it's going to solve the problem it was intended
    to.

That could be a problem, especially if the problem it's intended to solve
can't be precisely articulated in an implementation-independent way.

    > 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.

    Yes, of course.  However, it's possible to construct pathnames which
    might contain "syntax errors" by other means as well.  For instance, if
    you merge pathnames from two different hosts you might end up with
    subfields that are too long, illegal characters, etc.

I should have said parsing and merging and component setting, i.e. all
forms of pathname construction.