Re: issue TRUENAME-SYNTAX-ONLY

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

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

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

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

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

-Sandra
-------