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

* vnikolov@poboxes.com
| In article <3125529974610138@naggum.no>,
|   Erik Naggum <erik@naggum.no> wrote:
| 
|   > * 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.

  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?

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