If thing is a string then the substring of thing bounded
  by start and end is parsed into a pathname as follows:

  (...) ;first three cases (about logical pathnames) omitted

  * Otherwise, the parsing of thing is implementation-defined.

I.e. there are cases where it is implementation-defined whether
the namestring is interpreted as a logical pathname or as an
ordinary pathname.  If you really insist, we could go into more
details (but please cc your postings to me as I'm never sure
I'll get to reading the newsgroup).

Some namestrings can denote at the same time a logical
pathname and an ordinary one.  Sometimes the programmer
may want to control or override the implementation's
choice of one interpretation over the other, for which
#P is not sufficient.  Probably that was why ACL
introduced the #L reader syntax.  (I don't use ACL
myself but I have learned from a posting by Erik Naggum
that ACL has that syntax.)

Of course, there are probably many things I don't understand
(correctly), but I wish it were obvious which ones, at least to
myself...

Have nice times,
Vassil.

Vassil Nikolov <vniko...@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
   LEGEMANVALEMFVTVTVM  (Ancient Roman programmers' adage.)

* (pathname-as-directory #p"/home/")
#p"/home//"

(Not that it really matters, just aesthetics. A lot of the Debian
system scripts do this.)

  this is a false statement of fact.

  (please call them "physical pathnames", not "ordinary pathname".
  there's nothing extraordinary about a logical pathname.)

| Some namestrings can denote at the same time a logical pathname and an
| ordinary one.

  insofar as a physical pathname file-namestring may contain any random
  character, this is true, _but_, and this is the part that you should have
  understood by now, it is then parsed as a _logical_ pathname.  all that
  says is that you may want to force a _physical_ pathname.  there's no
  syntax for that, by the way.  if you want a file named "sys:foobar.lisp",
  you have to call MAKE-PATHNAME yourself.  so your stupid problem is only
  a problem because you got the facts reversed.

| Sometimes the programmer may want to control or override the
| implementation's choice of one interpretation over the other, for which
| #P is not sufficient.  Probably that was why ACL introduced the #L reader
| syntax.  (I don't use ACL myself but I have learned from a posting by
| Erik Naggum that ACL has that syntax.)

  what _is_ your beef with this?  this is second time you stupidly bring
  this up and it has _nothing_ to do with the issue at hand.  you don't
  understand why Allegro CL has #L, so you _assume_ a lot of bullshit about
  it and draw insane conclusions.  what does all that crap _do_ for you?

  does all of this rest on what you assume into that unwarranted "probably"
  of yours?  are you really upset that Allegro CL has a #L syntax and all
  of this insane drivel of yours is really trying to kick me or Allegro CL
  for having something you don't have?  is it pure envy?  is it some mental
  disorder?  the realm of the rational is too small to contain your drivel.

  here's the fact, if your brain is still capable of dealing with facts now
  that the evidence is out that it cannot separate facts from assumptions:
  #L calls LOGICAL-PATHNAME on the string following it.  some _partial_
  (i.e., strictly invalid) logical pathnames are assumed to be complete
  with a null logical pathname host.  this is useful in stuff like
  #L"**;*.*", which is otherwise _not_ a logical pathname namestring, but
  which is still forced into that in the context where you find it: which
  is in setting up logical pathname translations.

  the other use for #L is to be nice to the intelligent reader who doesn't
  get confused by it and go off rambling like a moron, which you have done.
  like designators, it's a service to people who know what they are doing.
  life is not a tutorial, and if you are the kind of person to base your
  life on guesses and unwarranted assumptions, it should hurt when your
  guesses are wrong.  just because it hasn't hurt so far doesn't mean you
  have never made wrong guesses.  more likely, nobody cared to tell you.

| See above.

  it should have been clear that I wanted you to explain them, not make
  _more_ unwarranted assumptions.  damn it, don't you even _know_ when you
  make assumptions?

| Of course, there are probably many things I don't understand (correctly),
| but I wish it were obvious which ones, at least to myself...

  it would have been if you had paid attention.

  huh?  FILE-NAMESTRING of #p"/home/" is _not_ NIL in CMUCL?

Groetjes, Peter

Hmm, I get #p"/home/" as the answer.

    Erik>   huh?  FILE-NAMESTRING of #p"/home/" is _not_ NIL in CMUCL?

On my version (file-namestring #p"/home/") returns "". A quick read of
CLHS says file-namestring returns a namestring.  NIL is not a
namestring is it?

  ok, so I'm _extra_ annoyed by illiterates lately, but can you guys please
  do me a f*cking favor and do your own homework, like looking for this
  line in the standard or HyperSpec under FILE-NAMESTRING and friends:

namestring---a string or nil.

  that's the return value from FILE-NAMESTRING.

  it isn't reasonable to return a string from any of these functions when
  the component or components in question are NIL.

  or does CMUCL return "" from (pathname-name #p"/home/"), too?  how about
  (host-namestring #p"/home/") or (directory-namestring #p"foo.bar")?

        * (FILE-NAMESTRING #p"/home/")

        ""
        * (pathname-name #p"/home/")

        NIL
        * (host-namestring #p"/home/")

        "Unix"
        * (directory-namestring #p"foo.bar")

        ""
        *

-Rob

  obviously, because I care.  no, I don't have to care, either, but if I
  didn't care, why the hell would I spend any time at all trying to learn
  new stuff from others as well as help those who want to learn something I
  know?  since I do care, I think those who pretend to want to learn, but
  really only want others to do their homework for them, are posting on
  fraudulent terms.  I don't think people should get away with fraud.  I'm
  sure you think it's none of your business, until _you_ get defrauded, but
  then you'll expect somebody else to care about it, like the police or
  whatever, but you can't take every fraud to the police, and if you don't
  react to small fraud, you pave the way for big fraud.

  I'm sure you don't understand any of this.  why should _you_ care?

  I thought we already had the convention that the empty _list_ was
  "nothing", but CMUCL apparently thinks its better to introduce typed
  nothings, like empty strings, too.  sigh.

  so, fine, let's test for the empty string in CMUCL, instead.  it gives
  the function a distinctly Scheme-ish flavor as in (not (null? x)), but
  what the heck, it's free software.

(if #+cmucl (< 0 (length file-namestring))
    #-cmucl file-namestring
  ...)

  the length test would work everywhere, but I want an empty string to be
  _different_ from no string.

  feel free to volunteer all the information you want.  why haven't you?
  maybe it's because you don't care about that, either?

  fraud -- an intentional perversion of truth for the purpose of inducing
  another in reliance upon it to part with some valuable thing belonging to
  him or to surrender a legal right.  a  false representation of a matter
  of fact, whether by words or by conduct, by false or misleading
  allegations, or by concealment of that which should have been disclosed,
  which deceives and is intended to deceive another so that he shall act
  upon to his legal injury.  anything calculated to deceive, whether by a
  single act or combination, or by suppression of truth, or suggestion or
  what is false, whether it be by direct falsehood or innuendo, by speech
  or silence, word of mouth or look or gesture.

  that's Black's law dictionary introducing the concept.

  I view time as a valuable asset, answering a question with technical
  answers that any conscientious person would know are wrong as false
  representation of a matter of act, and posting under false pretenses as
  concealment of that which should have been disclosed.  asking others to
  help you when your real purpose is to avoid doing your homework, is
  fraud.  not making sure you know that what you have posted is correct,
  yet make it appear that it is, is fraud.  inducing somebody to help you
  when you will not accept the responsibility of learning from it, is fraud.

  in a world where information is becoming a currency, there are a lot of
  counterfeiters who can't understand that what they are doing is wrong.
  are you one of those?  it looks that way from my point of view.

  a dejanews search on your fairly unique name returns 5 messages.  may I
  ask why you get so excited about my article that you had to post your
  message to begin with?  you seem to care about meaningless issues, but
  not about any serious issues related to this newsgroup or the Common Lisp
  programming language at all.  yet you have the right to question why
  _others_ care?  I think that is basically fraudulent of you, too.

On 14 Jan 1999 12:58:47 -0500, Raymond Toy <t...@rtp.ericsson.se>
wrote:

                                                       /L/e/k/t/u

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.5.3i; see <http://www.pgpi.com>

  (parse-namestring "foo;bar.baz" nil (make-pathname :host nil
                                                     :device nil
                                                     :directory nil
                                                     :name nil
                                                     :type nil
                                                     :version nil))

(with a semicolon between foo and bar---no explicit host)
it is implementation-dependent if the string will be parsed
as a logical pathname namestring?

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

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

One more thing:

In article <3125218436594...@naggum.no>,
  Erik Naggum <e...@naggum.no> wrote:

Vassil Nikolov <vniko...@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
   LEGEMANVALEMFVTVTVM  (Ancient Roman programmers' adage.)

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

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

(2) What in the standard forbids an implementation from having a
    `default logical host of last resort' which would be used for
    a parse when all other sources of a logical host for the parse
    do not supply one?  (`All other sources' are those that are
    mentioned in the first three cases that define how parsing
    is done when the <thing> argument to PARSE-NAMESTRING is a
    string.)

    (I have not been able to find a prohibition against having
    such a default.)

(3) In my understanding of logical pathnames at least, parsing
    a logical pathname namestring is a separate operation from
    translating a logical pathname (although typically they
    are performed immediately one after the other).  Further, my
    understanding is that a logical pathname namestring can be
    parsed even without a logical host at hand (on the other hand,
    translating one, of course, requires having a logical host).
    I.e., having decided that it is a logical pathname namestring,
    and applying the syntactic rules of such namestrings, I can
    produce from "foo;bar;baz.quux" a structure like:

      ((:directory (:absolute "foo" "bar"))
       (:name "baz")
       (:type "quux"))

    even in the absence of a logical host.  (If you ask why I may
    want to do that, one possible answer is for merging this with
    another pathname.)  Can you point me to a place in the standard
    that proves that my understanding is incorrect?

    (PARSE-NAMESTRING does parsing only without translating, does it
not?)

Have a nice day or night,
Vassil.

Vassil Nikolov <vniko...@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
   LEGEMANVALEMFVTVTVM  (Ancient Roman programmers' adage.)

  invalid reasoning.  you must show where and how the standard _supports_
  your position.  in brief: its absence from the exhaustively specified set
  of allowable logical hosts.

| (2) What in the standard forbids an implementation from having a
|     `default logical host of last resort' which would be used for
|     a parse when all other sources of a logical host for the parse
|     do not supply one?

  invalid reasoning.  you must show where and how the standard _supports_
  your position.  in brief, there is no such thing in the standard, and if
  there isn't, an implementation that has it, will in some way violate the
  standard semantics.

| (3) In my understanding of logical pathnames at least, parsing a logical
|     pathname namestring is a separate operation from translating a
|     logical pathname (although typically they are performed immediately
|     one after the other).

  huh?  they are _completely_ unrelated tasks.  your "typically" does not
  apply to any of the code I see that actually uses logical pathnames.
  whence your observation?

|     Further, my understanding is that a logical pathname namestring can
|     be parsed even without a logical host at hand (on the other hand,
|     translating one, of course, requires having a logical host).

  whence this understanding?  (it's false.)

|     Can you point me to a place in the standard that proves that my
|     understanding is incorrect?

  invalid reasoning.  you must show where the standard _supports_ your
  position.  places in the standard define what is correct.  if there is no
  place in the standard that proves it correct, _then_ it is incorrect.
  therefore, there is no place in the standard that proves it incorrect.
  the place that proves it incorrect is _outside_ of the standard, if
  anywhere.  it is the _absence_ of a place in the standard that proves it
  correct that proves your proposition incorrect.

|     (PARSE-NAMESTRING does parsing only without translating, does it not?)

  I fail to see what is unclear about what it does.  whence the uncertainty?

| I hope I have made it clear of what I am aware.

  no.  you apparently think that standards forbid things.  they don't.

  standards specify exhaustively what's valid and what all the valid stuff
  means.  everything else is forbidden.  if you cannot find support for
  your position in the standard, it is ipso facto not _standard_ behavior.

| By responding to (1)--(3) above, you may point me to something in the
| standard of which I am not aware, or which I have failed to interpret in
| the right way.  But please point me to specific places in the standard.
| You have stated your understanding of the matter; I am asking about how
| this understanding follows from the standard.

  my understanding of _any_ standard comes from having worked on half a
  dozen fairly large standards from early draft through to publication, and
  from owning copies of standards documents worth more than the average
  annual income in Norway.  put differently from above yet meaning exatly
  the same thing, standards provide the axiomatic framework for a deductive
  system of reasoning.  definitions, requirements, semantic interpretation,
  glossary, etc, are all working together to specify what the authors of
  standard intends to be legal and what everything that it says is legal
  shall mean.  if you cannot reach a conclusion by deduction from what the
  standard says is legal, it is _not_ legal.  true statements that cannot
  be proven are bugs.  contradictions are bugs.

| If it happens that a logical host has the same name as a physical host

  yeah, I can make out what this nonsense means, but why do I have to?

  the less willing you are to use the terminology of the standard, the more
  I'm inclined to think that you're fighting the terminology instead of
  using it to enhance your understanding of the fairly extensive semantic
  web that makes up a large document like the Common Lisp standard.

  standards are about _precision_.  I find it interminably boring to deal
  with people who want the fruits of precision, yet show zero respect for
  the foundations of such precision.  a standard isn't a document where all
  the difficult words are defined as "yeah, whatever", or "you know what I
  mean".  the effort that goes into writing (editing) a standard is truly
  tremendous.  in addition, Kent Pitman made this all available in a very
  usable hypertext form so that nobody has any excuse _not_ to follow
  glossary links and the like.

| ^2 unless, of course, it is guaranteed that PATHNAME always returns a
| physical pathname from a namestring, but I cannot find such a guarantee
| in the standard

  PATHNAME returns a `pathname' object [function pathname].  a physical
  pathname is a `pathname' that is not a `logical-pathname' [glossary].
  the class precedence list for `logical-pathname' is (logical-pathname
  pathname t) [system-class logical-pathname].

| For translating a logical pathname, yes; but for parsing?

  I haven't been talking about translating.  that's maximally irrelevant.

| Indeed, it should have been made clear from the beginning if we are
| talking about a function that _either_
| (A) tests if a string is a logical pathname namestring with respect
| to a _particular_ logical host, _or_ that
| (B) tests if there _may_exist_ a logical host with respect to which
| a string is a logical pathname namestring.
| I still say that (B) is not so trivial.  But it is not worth
| arguing further (including about the name) unless the need for
| such a function arises from a specific problem that we have at hand.

  what the fuck?  you call LOGICAL-PATHNAME-TRANSLATIONS to learn if a
  string names a logical host or not!  how hard can this be?

| As usual, if one knows what one is doing...

  do and know, or don't and learn.

    Erik>   ok, so I'm _extra_ annoyed by illiterates lately, but can you guys please
    Erik>   do me a f*cking favor and do your own homework, like looking for this
    Erik>   line in the standard or HyperSpec under FILE-NAMESTRING and friends:

    Erik> namestring---a string or nil.

    Erik>   that's the return value from FILE-NAMESTRING.

I admit that I only looked at these parts of CLHS:

        Syntax:
        ...
        file-namestring pathname => namestring

and

        Description:
        ...
        file-namestring returns just the name, type, and version components of pathname.

Since namestring was defined in the glossary, I didn't expect
namestring in this context to mean string or nil.

However, I can also read that CLHS says

        These functions convert pathname into a namestring. The name
        represented by pathname is returned as a namestring in an
        implementation-dependent canonical form.

(I'm sure you knew this, but momentarily forgot.)

So CMUCL can return whatever it feels like.

I do agree, however, that since pathname-name is NIL in this case,
NIL would be a good answer instead of the empty-string.  

(...)  ;on (FILE-NAMESTRING #p"foo/") => NIL or ""?

I don't think CL wants to exclude file systems where the empty
string is a valid file name.  (They would need some sort of
escape character syntax when parsing namestrings, of course, to
denote such a (strange) file name.)

Good luck,
Vassil.

Vassil Nikolov <vniko...@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
   LEGEMANVALEMFVTVTVM  (Ancient Roman programmers' adage.)

  actually, I came across something that implies that the empty string and
  nothing are the same for a certain point of view:

Parsing a null string always succeeds, producing a pathname with all
components (except the host) equal to nil.

  this is in the dictionary for PARSE-NAMESTRING.

  so at least (file-namestring ...) => "" is reversible, but I'd still like
  to see some stronger wording to ensure that NIL is the correct answer.
  the dictionary for for PARSE-NAMESTRING doesn't say anything about when
  to return NIL now.  for me, however, the intuitively evident is OK until
  people start to object.  then I need something more concrete.  sigh.

  the really pathetic thing here is that Unix used to treat the empty
  string as the current directory.  that's how a trailing slash worked...

  > * vniko...@poboxes.com
  > | (1) What in the standard _forbids_ NIL from being a logical host?
  >
  >   invalid reasoning.  you must show where and how the standard
_supports_
  >   your position.  in brief: its absence from the exhaustively
specified set
  >   of allowable logical hosts.

From the Glossary:
  logical host n. an object of implementation-dependent nature...

This does not look like an exhaustively specified set.  Can you
point me to this exhaustive specification?

  > | (2) What in the standard forbids an implementation from having a
  > |     `default logical host of last resort' which would be used for
  > |     a parse when all other sources of a logical host for the parse
  > |     do not supply one?
  >
  >   invalid reasoning.  you must show where and how the standard
_supports_
  >   your position.  in brief, there is no such thing in the standard,
and if
  >   there isn't, an implementation that has it, will in some way
violate the
  >   standard semantics.

The standard does not define explicitly _all_ aspects of logical
pathnames.  (For example, the definition of the logical host SYS
is implementation-dependent.  And isn't it legal for an implementation
to use NIL to represent the logical host whose name us "SYS"?)

Once again: is the case of

  (parse-namestring "foo;bar;baz.quux" nil (make-pathname :host nil))

doing the parse so that the resulting directory component is ("FOO"
"BAR"),
the resulting filename component is "BAZ", etc., illegal?  If so, why?

I say that the above matches the last case of the definition of what
PARSE-NAMESTRING does when it is passed a string, and the result in
that case is implementation-dependent.

  > | (3) In my understanding of logical pathnames at least, parsing a
logical
  > |     pathname namestring is a separate operation from translating a
  > |     logical pathname (although typically they are performed
immediately
  > |     one after the other).
  >
  >   huh?  they are _completely_ unrelated tasks.  your "typically" does
not
  >   apply to any of the code I see that actually uses logical
pathnames.
  >   whence your observation?

Hence: passing a logical pathname namestring to OPEN is typical use of
logical pathname namestrings; when this happens, the namestring is parsed
then translated.

  > |     Further, my understanding is that a logical pathname namestring
can
  > |     be parsed even without a logical host at hand (on the other
hand,
  > |     translating one, of course, requires having a logical host).
  >
  >   whence this understanding?  (it's false.)

Hence: parsing is a syntactic operation, and the syntax of a logical
pathname namestring makes the host optional.

  (...)

  > |     (PARSE-NAMESTRING does parsing only without translating, does
it not?)
  >
  >   I fail to see what is unclear about what it does.  whence the
uncertainty?

I just wanted to make sure that if I was missing something, it was not
with regards to what PARSE-NAMESTRING does.

  (...)
  >   standards specify exhaustively what's valid and what all the valid
stuff
  >   means.  everything else is forbidden.  if you cannot find support
for
  >   your position in the standard, it is ipso facto not _standard_
behavior.

Fine, but how does `implementation-dependent' fit into this?

  (...)
  >   standards provide the axiomatic framework for a deductive
  >   system of reasoning.
  (...)
  >   true statements that cannot
  >   be proven are bugs.  contradictions are bugs.

If I take this literally, then any standard has bugs by definition...

  (...)
  >   the less willing you are to use the terminology of the standard,
the more
  >   I'm inclined to think that you're fighting the terminology (...)

Would you give me specific examples of me fighting the terminology?
(If it is not too much trouble, that is.)

  (...)
  > | ^2 unless, of course, it is guaranteed that PATHNAME always returns
a
  > | physical pathname from a namestring, but I cannot find such a
guarantee
  > | in the standard
  >
  >   PATHNAME returns a `pathname' object [function pathname].  a
physical
  >   pathname is a `pathname' that is not a `logical-pathname'
[glossary].
  >   the class precedence list for `logical-pathname' is (logical-
pathname
  >   pathname t) [system-class logical-pathname].

Why did you post this?  This is not a guarantee that PATHNAME always
returns
a physical pathname from a namestring.

  (...)
  > | (B) tests if there _may_exist_ a logical host with respect to which
  > | a string is a logical pathname namestring.
  > | I still say that (B) is not so trivial. (...)
  >
  >   what the fuck?  you call LOGICAL-PATHNAME-TRANSLATIONS to learn if
a
  >   string names a logical host or not!  how hard can this be?

Do you mean that in order to do (B) one has to include a call to
LOGICAL-PATHNAME-TRANSLATIONS?

Anyway, does `not so trivial' mean `hard'?

Be well,
Vassil.

Vassil Nikolov <vniko...@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
   LEGEMANVALEMFVTVTVM  (Ancient Roman programmers' adage.)

If the standard does not expressly say that something is ok, then an
implication of having failed to specify it is that it has failed to
specify a meaning.  It has come up numerous times that people have
alleged that there are things which are "legal" but that have no
assigned "meaning".  Forgetting CL for the moment, and speaking only
as a philosopher, I have to say that this concept is not something
that resonates with me.  A language is for the purpose of expressing
something--if you do not know what you are expressing, then its
usefulness (at least in a program, though perhaps not in a museum of
modern art) is dubious.

Usually the issue being danced around is this:

 Sometimes the standard doesn't preclude something.
 That doesn't make use of that thing forbidden, but if no portable
 program can be written to use it, then it's really not meaningfully
 conforming of a program to use the feature.  HOWEVER, an implication
 is also that an implementation is not forbidden from assigning
 meaning to the item and still claiming to be conforming.  Implementations
 are permitted to extend the language, but usees of those extensions
 render a program non-conforming.  Not non-useful.  But to the degree
 that it has any use, it's either because you don't care about the program
 much and are willing to take any result that "appears to work" or else
 it's because you have verified with the relevant implementations that
 they will reliably provide the feature you want and that agreement is
 good enough that it suffices in place of a guarantee by the language
 that the feature will work.

In the case of NIL as a logical host, I think the problem is that NIL has
an assigned meaning as a merging element, and I'm pretty sure there is
a specific paragraph somewhere that says, approximately, "NIL is permissible
as a host component only in implementations where there is only one possible
host and a filler of NIL for the host cannot possibly be confused with
the absence of a filler".

  please try not to do this.  it's terribly hard to untangle this mess.

| From the Glossary:
|   logical host n. an object of implementation-dependent nature...
|
| This does not look like an exhaustively specified set.  Can you point me
| to this exhaustive specification?

  it is becoming evident that this has changed from a desire to understand
  the standard to silly bickering over irrelevant trivia.  it also appears
  that you focus on particular details of expression, not on the meaning
  that is attempted expressed.  interpreting standards is very much like
  applying laws to a particular case at hand.  instead of letting everbody
  go through technicalities and insufficiencies, there's a concept called
  "the spirit of the law".  a truly phenomenal amount of effort goes into
  extracting the spirit of the law from the body of laws and precedents,
  and this process has a purpose and a reason: there's a mythical principle
  that all of the miserably fallible human beings are trying to express.
  it is nigh impossible to say anything so people elsewhere at other times
  will know _exactly_ what you meant and why you said what you said.  just
  like you do here, people tend to have their own principles and want what
  they see from others to fit them.  it takes constant vigilance to fight
  that probable inherent limitation of the human intellect -- we weren't
  used to having to deal with so much information that turned invalid at
  the blink of an eye until late in this century, and there is ample
  evidence that humans, like other sentient beings, go crazy when all they
  deal with is new information.  our filters and the way we think and act
  is defined in terms of what has _not_ changed since yesterday.  knowing
  this, it is even more important to see what kinds of things change and
  what kinds of things don't change, and all the while remain open to an
  error in those assessments of constancy.

  in this case, you've made up your mind about something being allowed by
  the standard, but because I can't _disprove_ it your satisfaction, you
  think you are in the clear when it comes to saying that the standard
  _allows_ it in the same sense that laws do it: they don't forbid it.  but
  that isn't how standards work.  a standard is like a constitution: it
  says what procedures must be followed to make a law be fully legal.  a
  standard binds the implementors the same way the U.S. Constitution binds
  the states: it says what they must do under threat of non-conformance,
  and constitutional law is about showing that something does _not_ follow
  from the constitutionally specified procedures.  if it does not follow,
  it is no a valid law.  just like the U.S. Constitution allows the states
  to do a lot of stuff on their own, a standard leaves a lot of options
  open to the implementors, but they are _not_ allowed to overturn or
  contradict the Constitution or the standard, and will be struck down if
  they try to, with exactly the same procedure: if you can't prove it's a
  valid law, you can't use it against anybody.

  now, this analogy will fail if you aren't interested in law and legal
  philosophy, but I am and have been for all my life, so reading standards
  really comes as a breeze to me compared to dealing with the much less
  specifically targeted legal traditions that also have to deal with
  changing desires of the public to which the laws are intended to be
  applied.  (for a great example on the intricacies of procedure, I
  recommend that you read Robert's Rules of Order.  I rushed to get the new
  edition when it came out 1991.  I don't know anybody else who did.)

| (For example, the definition of the logical host SYS is
| implementation-dependent.  And isn't it legal for an implementation to
| use NIL to represent the logical host whose name us "SYS"?)

  no.  nowhere in the standard does it say that.  therefore, it is not
  legal.

| I say that the above matches the last case of the definition of what
| PARSE-NAMESTRING does when it is passed a string, and the result in
| that case is implementation-dependent.

  an implementation is not allowed to add semantics to logical pathnames.
  it is allowed to do anything it pleases with physical pathnames.  so when
  the result is implementation-dependent, it means it is a physical
  pathname -- the whole purpose of the logical pathname facility is to be
  implementation-independent.  it would self-contradictory if parsing
  something in an implementation-dependent way would be a means to obtain
  implementation-independent behavior.  self-contradictions are usually a
  pretty good sign you got something very seriously wrong.

| Hence: passing a logical pathname namestring to OPEN is typical use of
| logical pathname namestrings; when this happens, the namestring is parsed
| then translated.

  I see no evidence that this is typical.  parsing is pretty expensive, to
  is makes ample sense to do it early.  Common Lisp lets you do that with a
  simple #P in front of the namestring.  why would anyone go out of their
  way to fail to use that facility?  I don't get it.  if it's typical,
  let's tell the kids scary stories so at least the next generation won't.

| Hence: parsing is a syntactic operation, and the syntax of a logical
| pathname namestring makes the host optional.

  ok, so your argument rests on that optionality of the host component in
  the syntax specification, not on a solid understanding of what the syntax
  is supposed to mean?  that's bickering over the letter of the law, and
  it's usually enough to land you a "contempt of court" ruling if you try
  it in any official capacity.

| Fine, but how does `implementation-dependent' fit into this?

  I hope you understand this by now.  if not, the standard actually has a
  lot of good things to say about this issue itself.

|   (...)
|   >   standards provide the axiomatic framework for a deductive
|   >   system of reasoning.
|   (...)
|   >   true statements that cannot
|   >   be proven are bugs.  contradictions are bugs.
|
| If I take this literally, then any standard has bugs by definition...

  truly amazing.  I did consider putting in a disclaimer about Gödel here,
  but figured nobody would be so utterly incapable of understanding context
  they would bring it up, but, what is the world if not full of surprises?

  try to take things less literally, and please go read Gödel.  you might
  be surprised what he's _actually_ talking about.  applying Gödel to this
  case is like believing competition in the market place has anything to do
  with Darwinian theory of evolution.

| Would you give me specific examples of me fighting the terminology?
| (If it is not too much trouble, that is.)

  your reference to the incompleteness theorems above is sufficient proof.

| Why did you post this?

  because it looked like you needed it.  why else?

| Do you mean that in order to do (B) one has to include a call to
| LOGICAL-PATHNAME-TRANSLATIONS?

  effectively, yes.  

| Anyway, does `not so trivial' mean `hard'?

  on a scale from N to M, "not so trivial" is j and "hard" is k.  i.e.,
  your question is completely devoid of meaning, and any answer is as good
  as any other answer.  "hard" could be simpler than "not so trivial" in
  some contexts and the reverse in others.

  tell me, why is this is stuff so hard for you to deal with?

(defun pathname-as-dir (pathname)
   (setq pathname (pathname pathname))
   (let ((filename (file-namestring pathname)))
      (if  #+lispworks (< 0 (length filename))
         #-lispworks filename
         (make-pathname :defaults pathname
           :directory (append (pathname-directory pathname)
                        (list filename))
           :name nil :type nil :version nil)
         pathname)))

(defun dirt (startpath &optional (tab 0))
   (dolist (path (directory startpath))
      (format t "~V,0T~A~%" tab path)
      (dolist (subpath (directory (pathname-as-dir path)))
         (dirt subpath (1+ tab)))))