Subject: Re: A portable DIRECTORY-P. Re: Here we go again. More CMUCL/ACL pathname differences.
From: Erik Naggum <>
Date: 1999/01/16
Newsgroups: comp.lang.lisp
Message-ID: <>

| I said that the answer is yes (implementation-dependent);
| if you say the answer is no, would you please demonstrate why not?

  this is entirely faulty reasoning.  my point is that the case of the
  logical pathname is defined and constrained in the standard.  whatever is
  left is a candidate for implementation-defined parsing as a physical
  pathname, not as a logical pathname, since that has been exhaustively
  defined.  the case you have brought up is nowhere near the conditions for
  parsing as a logical pathname.  I have to ask you why you think this is a
  valid example in the first place.  NIL would have to be a logical host in
  some implementations and not in others for this example to make sense, if
  I read it right.  that is clearly not a tenable position.

| There are two cases:
| (1) X is parsed as a logical pathname namestring but the programmer
|     would like it to be parsed as a physical pathname namestring;
| (2) X is parsed as a physical pathname namestring but the programmer
|     would like it to be parsed as a logical pathname namestring.
| Above, you discuss (1), don't you?  My concern, however, was with (2).
| (Why did you write as if my concern was with (1)?)

  because 2 is excluded by the standard and it doesn't make sense to
  discuss settled issues.  if you were not aware that it was settled,
  that's a slightly different discussion than one where you assume it not
  settled and want to discuss consequences of it not being settled.

| (One more thing: although (1) is not my problem, it could well be
| somebody's problem when namestrings are supplied to a program from
| outside as data (at run-time).  The one who supplies them may want them
| to be treated as physical pathnames.)

  true, and this has been what I've been trying to address, since the
  reverse situation doesn't happen.  it appears to me that a HOST argument
  that is neither a logical host nor NIL should force parsing as a physical

| Is "foo;bar;baz.quux" a logical pathname namestring?

  no.  (I assume that this is the crux of your argumentation.)

| The syntax for logical pathname namestring makes the host part optional.

  no.  the host is optional when _otherwise_ provided to PARSE-NAMESTRING.
  all logical pathnames have a logical host as their host component.  if it
  is optional, it has to come from somewhere, it cannot be assumed, and it
  cannot be NIL.  physical pathnames, on the other hand, may have a NIL
  host component.

| Now, let me point out one reason why I say that is not so trivial.
| PARSE-NAMESTRING needs a <host> and a <default-pathname> (not supplied
| above) in order to do the right thing in all cases when <namestring>
| should be parsed as a logical pathname namestring.  (This means that
| LOGICAL-PATHNAME-NAMESTRING-P may also need additional arguments.)

  the `default-pathname' argument defaults to *DEFAULT-PATHNAME-DEFAULTS*,
  so that's more or less taken care of.  if you intend to parse against a
  particular logical host and take advantage of the then optional host
  component, you ask a different question than "is this a logical pathname
  namestring?"  your question is now "is this a logical pathname namestring
  for the given host?"  in other words, you'll get a negative reply to all
  logical pathname namestrings that have a host mismatch.  I don't think
  the function that returns that answer should be called LOGICAL-PATHNAME-
  NAMESTRING-P.  furthermore, I think PARSE-NAMESTRING is sufficient for
  this more complicated case, and I see no reason why it is not sufficient
  for the general case, which is why I think nobody has thought of making
  it part of the standard.

  you may find lower-level functions used to implement PARSE-NAMESTRING
  that test for logical pathname namestring syntax if you look for them,
  however.  I'm not sure it's a good idea to call them from user code even
  if you find them.