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


<<Kent asks that we defer the PATHNAME issues beyond the letter ballot. I
think that is OK, and I am not planning to get more than those issues that
were pending prior to the October meeting ready for the letter ballot; I
expect we will have some more to present and discuss in the January
meeting, however.>>

I think that the clarification could be more constructive than
EXPLICITLY-VAGUE and yet also remain vague.

First, I believe the "partial specification" argument that it might be
useful and valuable for pathnames to have no explicit namestring, because
the pathname is being used for holding data that will be subsequently
merged. Thus, I would prefer to require that MERGE-PATHNAME, MAKE-PATHNAME
etc. not signal errors if given arguments of the correct type.

Secondly, we can say that NAMESTRING may signal an error even if given a
pathname, if no such namestring could be constructed (and the error type);
in addition, OPEN and other functions that take a pathname might also
signal a (different) error if no such file existed.

This would put the burden of consistency checking on NAMESTRING and its
internal equivalent; if such consistency checking is necessary at all, it
would be necessary in NAMESTRING. It also would separate out the error

I have no opinion about what the error types should be, as long as they are
more well specified than "ERROR".