Subject: Re: interpreting namestrings? (Ex: Re: A portable DIRECTORY-P...)
From: Erik Naggum <erik@naggum.no>
Date: 1999/01/17
Newsgroups: comp.lang.lisp
Message-ID: <3125529974610138@naggum.no>

* vnikolov@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.

| (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
-- 
  SIGTHTBABW: a signal sent from Unix to its programmers at random
  intervals to make them remember that There Has To Be A Better Way.