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


> Date: Wed, 14 Sep 88 15:54 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> Perhaps you can come up with a better description of what :SYNTAX-ONLY
> does?  I appear to have struck out.

This issue seems to be getting bogged down in a morass; therefore, I
would like to withdraw my proposal.  You've already indicated that you
would oppose the proposal on the grounds that it would take a
"near-infinite" amount of time to implement unless the behavior is
explicitly left vague, so there doesn't seem much point to my trying
to further clarify what the function must do. 

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

I think you're confusing "implementation-independent" with
"file-system-independent".  As I have grumbled about before, all of
the pathname functions have this problem, not just the proposed
extension to TRUENAME.  I think that the only alternative is to come
up with rules that all implementations must obey for specific file
systems: For files on BSD Unix hosts, the following values may be
supplied for such-and-such a pathname component.  For files on VMS
hosts, this function returns X; for files on an MS-DOS host, the
function returns Y.  Unless and until the standard goes into this kind
of detail, I don't think that *any* of the Common Lisp pathname
functions (except for coercion between namestrings and pathname
objects) can be used portably across implementations, even
implementations running on the same host.  Granted, tightening up the
spec would cause implementors more work, but without it you might as
well throw out the pathname functions entirely, for all the good they
do users who are trying to write portable programs.