Subject: Re: Known inconsistencies or bugs in CLHS? From: Erik Naggum <erik@naggum.net> Date: Fri, 12 Apr 2002 16:44:39 GMT Newsgroups: comp.lang.lisp Message-ID: <3227618679020673@naggum.net> * Sam Steingold <sds@gnu.org> | #P"" is an ambiguous representation since #P".a.b" can mean either | #S(PATHNAME :NAME ".a" :TYPE "b") | or #S(PATHNAME :NAME ".a.b" :TYPE NIL) | or #S(PATHNAME :NAME NIL :TYPE "a.b") | (if you think that the first version is "obviously correct", think again | about ".foo"...) The mapping from namestrings to pathnames is implemention-specific. There is no ambiguity. You make an implementation-specific choice, then stick to it and make it consistent enough for your implementation, or you implement a more general mechanism and provide your programmers with a "policy switch" or even access to the maestring parser internals. None of this makes the _specification_ ambiguous. Ambiguous would mean that the _implementation_ had so low quality and was so poorly done that it could produce the same namestring for different pathnames. If so, you cannot blame the standard for this form of ambiguity. E.g., /foo/bar/../zot may interpret the .. as :back or as :up. Under Unix, no programmer would think about this, thus creating an ambiguity and a messy interpretation for pathnames with .. components, but Common Lisp has both :back and :up as distinct components, so you have to make a choice and a policy decision, thus _diambiguating_ the messy situation in Unix. (Of course, the Unix kernel specification has one policy, but the existence of symbolic links make it very hard to look at the components one by one without consulting the file system.) /// -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief. Post with compassion: http://home.chello.no/~xyzzy/kitten.jpg