Subject: Re: interpreting namestrings? (Ex: Re: A portable DIRECTORY-P...) From: Erik Naggum <firstname.lastname@example.org> Date: 1999/01/17 Newsgroups: comp.lang.lisp Message-ID: <email@example.com> * firstname.lastname@example.org | (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.