Hello,
Recently, I've run into the special problem that
compiler-macro-function returning NIL does not work in CMUCL (in
contrast to what is written in the CLHS glossary on
compiler-macro-function). I then found out that this topic was
discussed in c.l.l. already, and KMP's opinion in
http://groups.google.com/groups?hl=en&selm=sfwso497n0f.fsf%40world.std.com
is that both returning the original form and the symbol NIL should
work. Now, neither CMUCL nor ACL understand returning NIL, and after
asking on the CMUCL mailing list about this, I am left with the
impression that this is an inconsistency within the Hyperspec (when
reading it first, it seemed unnatural to me as well).
To prevent meeting such a CLHS (or ANSI standard) problem again: what
further inconsistencies or bugs are known?
Thank you, Nicolas.
P.S.: This may be a very bad question to ask (hopefully it is not).
Please, don't have too long discussions about each single point... :-)
From: Christophe Rhodes
Subject: Re: Known inconsistencies or bugs in CLHS?
Date:
Message-ID: <sqofgp6r7z.fsf@cam.ac.uk>
Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
> To prevent meeting such a CLHS (or ANSI standard) problem again: what
> further inconsistencies or bugs are known?
There is a simple typo (or cut'n'paste error :-) in the description
for prog2:
prog2 evaluates first-form, then second-form, and then forms,
yielding as its only value the primary value yielded by first-form.
where that last word should be "second-form". The "Syntax" section
(just above) gets it right.
There's an inconsistency in the examples for format ~R:
(format nil "~19,0,' ,4:B" 3333) => "0000 1101 0000 0101"
The last time we discussed this, the consensus as I recall was that it
should return "000001101 0000 0101" -- but you might want to check
google for that...
Those are the two that I can remember off the top of my head; I'm not
promising that this is a comprehensive list :-)
Cheers,
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Christophe Rhodes <·····@cam.ac.uk> writes:
> Those are the two that I can remember off the top of my head; I'm not
> promising that this is a comprehensive list :-)
It's possible that I've found another... either that or I've lost the
pathname plot completely:
Function USER-HOMEDIR-PATHNAME
Syntax:
user-homedir-pathname &optional host => pathname
Arguments and Values:
host---a string, a list of strings, or :unspecific.
"a list of strings"? Should that read "a logical pathname host"? What
does it mean? Where does it come from?
Baffled,
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Christophe Rhodes <·····@cam.ac.uk> writes:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
> > Those are the two that I can remember off the top of my head; I'm not
> > promising that this is a comprehensive list :-)
>
> It's possible that I've found another... either that or I've lost the
> pathname plot completely:
>
> Function USER-HOMEDIR-PATHNAME
> Syntax:
> user-homedir-pathname &optional host => pathname
> Arguments and Values:
> host---a string, a list of strings, or :unspecific.
>
> "a list of strings"? Should that read "a logical pathname host"? What
> does it mean? Where does it come from?
>
> Baffled,
I think this is worst than that. Essentially the whole notion of
`host' is essentially undefined in ANSI. It does not even appear in
the Glossary. And the definition of PATHNAME-HOST is not helpful.
So. The only reasonable course of action here is to get the
implementors to agree on what they want in the HOST component.
Xanalys and Franz people, what do *you* think? (Given that NIL is not
necessarily a good thing to have in there).
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
From: Erik Naggum
Subject: Re: Known inconsistencies or bugs in CLHS?
Date:
Message-ID: <3228152797754759@naggum.net>
* Marco Antoniotti <·······@cs.nyu.edu>
| I think this is worst than that. Essentially the whole notion of
| `host' is essentially undefined in ANSI. It does not even appear in
| the Glossary. And the definition of PATHNAME-HOST is not helpful.
Huh? The entry for pathname-host has glossary links to "valid pathname
host". There are also glossary entries on logical host and logical host
designator. The function host-namestring returns the host name, clearly
a string.
| So. The only reasonable course of action here is to get the implementors
| to agree on what they want in the HOST component.
A string should always suffice.
| Xanalys and Franz people, what do *you* think? (Given that NIL is not
| necessarily a good thing to have in there).
Franz Inc does not appear to believe in pathnames and so give them a very
low priority. It should not be possible to use nil as an _actual_ host,
but that is precisely what their pathname implementation does; even
host-namestring returns nil! It does accept the empty string as the host
argument to parse-namestring, though. CMUCL's host-namestring returns
"Unix", yet it does not understand when the same value is attempted to be
used as a valid pathname host, and the empty string signals an error.
CLISP appears to accept the empty string as the system physical host and
return it as the host-namestring, and so, apparently, does LispWorks. I
found this variation among implementations quite fascinating.
///
--
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
Erik Naggum <····@naggum.net> writes:
> * Marco Antoniotti <·······@cs.nyu.edu>
> | I think this is worst than that. Essentially the whole notion of
> | `host' is essentially undefined in ANSI. It does not even appear in
> | the Glossary. And the definition of PATHNAME-HOST is not helpful.
>
> Huh? The entry for pathname-host has glossary links to "valid pathname
> host". There are also glossary entries on logical host and logical host
> designator. The function host-namestring returns the host name, clearly
> a string.
Well, that's not what the CLHS says -- in the entry for
host-namestring, it says
namestring---a string or nil.
I think that it's /possible/ to make a nil return value consistent
with the rest of the system, though it makes parse-namestring less
useful for physical pathnames; I concede that it's ugly, but I'm not
convinced that there's a completely clean solution to putting CL
pathnames on a Unix system... at least, not without sacrificing the
obvious representation for physical namestrings.
> [...] I found this variation among implementations quite fascinating.
Yes. I think it's a tricky area, with a lot of pitfalls and blind
alleys.
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
From: Erik Naggum
Subject: Re: Known inconsistencies or bugs in CLHS?
Date:
Message-ID: <3228204118313722@naggum.net>
* Christophe Rhodes <·····@cam.ac.uk>
| Well, that's not what the CLHS says -- in the entry for host-namestring,
| it says
|
| namestring---a string or nil.
Thanks, I managed to overlook that, since pathname-host is not allowed to
return nil -- ah, no, wait. A valid physical pathname host may be a list
of strings, so the empty list is the degenerate case. How annoying. I
tend to think of "list of strings" as a non-empty list unless explicitly
allowed to be empty with "possibly empty list of strings" or something.
| I think that it's /possible/ to make a nil return value consistent with
| the rest of the system, though it makes parse-namestring less useful for
| physical pathnames; I concede that it's ugly, but I'm not convinced that
| there's a completely clean solution to putting CL pathnames on a Unix
| system... at least, not without sacrificing the obvious representation
| for physical namestrings.
I think the empty string for host does a good job of ensuring physical
pathname parsing. The empty string is not a good logical hostname, since
it would mean pathnames would come out with a leading colon. From what I
recall of Kent's description of the Genera way, a leading colon would
force physical parsing, indicating that an empty host-namestring has some
precedence with this meaning.
///
--
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
Erik Naggum <····@naggum.net> writes:
> * Marco Antoniotti <·······@cs.nyu.edu>
> | I think this is worst than that. Essentially the whole notion of
> | `host' is essentially undefined in ANSI. It does not even appear in
> | the Glossary. And the definition of PATHNAME-HOST is not helpful.
>
> Huh? The entry for pathname-host has glossary links to "valid pathname
> host". There are also glossary entries on logical host and logical host
> designator. The function host-namestring returns the host name, clearly
> a string.
No, I meant that "HOST" is not in the glossary. You can assume many
things here. Unfortunately this is one of the things that way too
many people take fro granted, while forgetting the devil lurking in
the details.
> | So. The only reasonable course of action here is to get the implementors
> | to agree on what they want in the HOST component.
>
> A string should always suffice.
>
> | Xanalys and Franz people, what do *you* think? (Given that NIL is not
> | necessarily a good thing to have in there).
>
> Franz Inc does not appear to believe in pathnames and so give them a very
> low priority. It should not be possible to use nil as an _actual_ host,
> but that is precisely what their pathname implementation does; even
> host-namestring returns nil! It does accept the empty string as the host
> argument to parse-namestring, though. CMUCL's host-namestring returns
> "Unix", yet it does not understand when the same value is attempted to be
> used as a valid pathname host, and the empty string signals an error.
> CLISP appears to accept the empty string as the system physical host and
> return it as the host-namestring, and so, apparently, does LispWorks. I
> found this variation among implementations quite fascinating.
Exactly my point. The gist of my post was to see if you could get the
implementors to agree.
There are several issues here and Kent's "Genera Rule" is a good
starting point, which, unfortunately is badly hurt by the MacOS choice
of ':' as a pathname component separator.
So, here it is, what do people at Corman, Digitool, Franz, Xanalys and
the non commercial places think?
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
"Marco Antoniotti" <·······@cs.nyu.edu> wrote in message
····················@octagon.mrl.nyu.edu...
>
> Erik Naggum <····@naggum.net> writes:
>
> > * Marco Antoniotti <·······@cs.nyu.edu>
> > | I think this is worst than that. Essentially the whole notion of
> > | `host' is essentially undefined in ANSI. It does not even appear in
> > | the Glossary. And the definition of PATHNAME-HOST is not helpful.
>
> > | So. The only reasonable course of action here is to get the implementors
> > | to agree on what they want in the HOST component.
> >
> > | Xanalys and Franz people, what do *you* think? (Given that NIL is not
> > | necessarily a good thing to have in there).
> >
> So, here it is, what do people at Corman, Digitool, Franz, Xanalys and
> the non commercial places think?
LW returns the local home directory of the current user if no host is specified
and NIL if a host is specified. I don't know a reliable way to find home
directory information for a different UNIX or Windows host or a reliable way to
use the resulting pathname from the current host, so NIL seems like the best
choice.
--
Martin Simmons
······@xanalys.com
rot13 to reply
From: Sam Steingold
Subject: Re: Known inconsistencies or bugs in CLHS?
Date:
Message-ID: <m3ofgpt1wc.fsf@gnu.org>
> * In message <··············@ortler.iwr.uni-heidelberg.de>
> * On the subject of "Known inconsistencies or bugs in CLHS?"
> * Sent on 12 Apr 2002 13:48:17 +0200
> * Honorable Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
>
> To prevent meeting such a CLHS (or ANSI standard) problem again: what
> further inconsistencies or bugs are known?
pathnames are required to be printed as #P"" when *PRINT-READABLY* is
non-NIL even though when *PRINT-READABLY* is non-NIL objects must be
printed so that reading them back results the a similar object.
#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"...)
This #S(PATHNAME) notation, used in some examples in the standard,
would have been unambiguous (and Kent said that he wanted it to become
the readable PATHNAME notation), but it did not make it into the
standard.
--
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
<http://www.palestine-central.com/> <http://www.mideasttruth.com/>
Whom computers would destroy, they must first drive mad.
From: Erik Naggum
Subject: Re: Known inconsistencies or bugs in CLHS?
Date:
Message-ID: <3227618679020673@naggum.net>
* Sam Steingold <···@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
Erik Naggum <····@naggum.net> writes:
> 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.
Actually, we had a term we used internally on the "to do" list for the
cleanups we were voting on and the editorial updates that resulted in the
spec: "explicitly vague". There are places where the spec, by virtue of
failing to make the issues perspicuous, leads people down the garden path
to believing they will find something that doesn't give them flexibility.
Over and over, people get confused by this and you're right to point out that
people who think the world is full of "uniquely defined behaviors" will get
their nose bloodied often when they fail to understand the implications of
terms like "implementation-defined". People often assume, for example, that
at least within a given file system there is somehow only one answer, since
had that file system been known to be uniquely determined by the ANSI CL there
probably would have been only one answer, but what they don't understand is
that it would have required _work_ to achieve that one answer and we didn't
do that work and then push the answer off to the vendors, we pushed the
_question_ off to the vendors, which means that an answer requires
negotiation/cooperation among those who use the same constraints.
> 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.
I think people use "ambiguous" in a lot of incompatible ways, such that
the term itself is ill-defined and invites confusion of this sort.
It's a side-track to pick on the terminology because the practical issue
is that these points that people call ambiguous are, whatever one calls
them, still locations where a lot of people get "snagged" for whatever
reason, and so just as the theoretical underpinnings of a FAQ might be
questioned, good faqs really do focus on the "F" (frequency) since that's
what helps the most people.
> 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.)
Btw, I've also been told, independent of symbolic links, it is (or
once was) possible to construct pathological file systems where .. can
be made not to point back to the parent and that this is also part of
the underlying reason for distinguishing up/back. It was observed to
me that the clever cracker could use this to trick people in various
subtle ways... there might even have been some legitimate uses, but
apparently not many, since in practice I've never heard of it really
being done. You're right that symbolic links are the more practical
issue. I think Multics also had the up/back "issue".
On Fri, 12 Apr 2002, Kent M. Pitman wrote:
> Erik Naggum <····@naggum.net> writes:
[...]
>> 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.)
>
> Btw, I've also been told, independent of symbolic links, it is (or
> once was) possible to construct pathological file systems where .. can
> be made not to point back to the parent and that this is also part of
> the underlying reason for distinguishing up/back.
I don't know about the underlying reason, but a good many filesystems
out there in Unix-land today suffer this effect. It's still popular to
store a '..' record in a directory, pointing to it's parent directory.
This means that you have a doubly-linked tree of directories, something
which can be useful for fsck to verify that things still make sense
internally.
> It was observed to me that the clever cracker could use this to trick
> people in various subtle ways... there might even have been some
> legitimate uses, but apparently not many, since in practice I've never
> heard of it really being done.
I have, on two occasions, encountered a file-system corruption that
resulted in weird '..' inconsistencies. One was an extremely old FFS
with one of the free *BSD set, where following '..' in a certain
directory would hard-reset the machine.[1]
The other was fixed by fsck after someone noted that '..' went to the
wrong directory after a crash.
> You're right that symbolic links are the more practical issue.
Also, hard links can make this a nightmare...
Daniel
Footnotes:
[1] x86 triple fault reset, actually. Very poor showing.
--
The best way to get information on Usenet is not to ask a question,
but to post the wrong information.
-- Aahz's Law
From: Erik Naggum
Subject: Re: Known inconsistencies or bugs in CLHS?
Date:
Message-ID: <3227690474302303@naggum.net>
* Daniel Pittman <······@rimspace.net>
| I don't know about the underlying reason, but a good many filesystems
| out there in Unix-land today suffer this effect. It's still popular to
| store a '..' record in a directory, pointing to it's parent directory.
Whether you store it or not, it is part of the file system semantics that
"." and ".." exist. If the requirement is also popular, that is great.
| This means that you have a doubly-linked tree of directories, something
| which can be useful for fsck to verify that things still make sense
| internally.
It is used to find the pathname of the current working directory, and
hence the physical truename of a file. It is used to find sibling
directories. It is, surprisingly, used to find the parent directory.
| Also, hard links can make this a nightmare...
Modern Unix/Linux kernels do not allow user code to hardlink directories.
///
--
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
From: Sam Steingold
Subject: Re: Known inconsistencies or bugs in CLHS?
Date:
Message-ID: <m3d6x4u3s6.fsf@gnu.org>
> * In message <················@naggum.net>
> * On the subject of "Re: Known inconsistencies or bugs in CLHS?"
> * Sent on Fri, 12 Apr 2002 16:44:39 GMT
> * Honorable Erik Naggum <····@naggum.net> writes:
>
> * Sam Steingold <···@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"...)
>
> 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.
could you please evaluate the following forms in the implementation you
are using and show us the results? thanks
(setq *print-readably* t)
(setq p1 (make-pathname :name nil :type "foo.")) ==> #P".foo." [CLISP]
error: unprintable readably [CMUCL]
(setq p2 (make-pathname :name ".foo." :type nil)) ==> #P".foo." [CLISP, CMUCL]
(setq p3 (make-pathname :name "" :type "foo.")) ==> #P".foo." [CLISP, CMUCL]
(setq p4 (make-pathname :name ".foo" :type "")) ==> #P".foo." [CLISP, CMUCL]
check that all pathnames are different (using EQUALP)
since all 4 pathnames have the same namestrings, only one of them
should be printable readably.
Which one is it in your implementation?
At any rate, even if your implementation does manage to select one of
the 4 consistently, using #S(PATHNAME) would have allowed readable
printing of all 4 pathnames.
--
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
<http://www.palestine-central.com/> <http://www.mideasttruth.com/>
(let ((a "(let ((a %c%s%c)) (format a 34 a 34))")) (format a 34 a 34))
From: Erik Naggum
Subject: Re: Known inconsistencies or bugs in CLHS?
Date:
Message-ID: <3227635213854286@naggum.net>
* Sam Steingold <···@gnu.org>
| could you please evaluate the following forms in the implementation you
| are using and show us the results? thanks
No. That is a _completely_ bogus approach to resolving this issue.
| Which one is it in your implementation?
Irrelevant. I am discussing language issues, not implementation issues.
I may consider an implementation broken after I understand the language
issue, and whether I used to use it or not is completely irrelevant and
the question a gave insult to those who want to help you resolve a
language issue. If you were talking public polls about what various
implementations were doing, you should have said so from the start.
EOD.
///
--
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
Sam Steingold <···@gnu.org> writes:
> pathnames are required to be printed as #P"" when *PRINT-READABLY* is
> non-NIL even though when *PRINT-READABLY* is non-NIL objects must be
> printed so that reading them back results the a similar object.
>
> #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")
or none of the above, since i don't recall anywhere it's said that
there must be a #\. separator between path name and type. Logical
pathnames aside, I mean.
I don't think this is a bug in CLHS, though - namestring parsing is
implementation-defined, so I'd say that if you print a pathname and
read it back in the same implementation to get a different answer,
that's a bug in the implementation. If you want a similar object even
when read in a _different_ implementation, there are other things to
start worrying about too. Floating-point numbers, for example.
Incompatible character sets ...
> (if you think that the first version is "obviously correct", think again
> about ".foo"...)
I'm a bit dubious about your third possibility, actually, because
leaving the name as NIL will allow it to be merged from defaults in
a merge-pathname call - or from *default-pathname-defaults* when
accessing the file system. I think this is probably not what you
want; perhaps use "" instead?
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Sam Steingold <···@gnu.org> writes:
> > * In message <··············@ortler.iwr.uni-heidelberg.de>
> > * On the subject of "Known inconsistencies or bugs in CLHS?"
> > * Sent on 12 Apr 2002 13:48:17 +0200
> > * Honorable Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
> >
> > To prevent meeting such a CLHS (or ANSI standard) problem again: what
> > further inconsistencies or bugs are known?
>
> pathnames are required to be printed as #P"" when *PRINT-READABLY* is
> non-NIL even though when *PRINT-READABLY* is non-NIL objects must be
> printed so that reading them back results the a similar object.
>
> #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")
or #S(PATHNAME :NAME ".A" :TYPE "B")
or #S(PATHNAME :NAME ".A.B" :TYPE NIL)
or #S(PATHNAME :NAME NIL :TYPE "A.B")
or #S(PATHNAME :NAME ".A.B" :type :UNSPECIFIC).
or #S(PATHNAME :NAME ".a.b" :type :UNSPECIFIC).
The first four depending on how the lisp chooses to model internal case.
As has been noted, this is all just in the realm of
implementation-defined. Once defined, it is not ambiguous at all.
But in general, ambiguity often has at least three axes: (a) the
wording chosen expresses lack of knowledge about the truth [incomplete
or badly explained information] (b) the wording chosen expresses
permission for the truth to be other than it is [permissional leeway]
(c) the wording chosen is such that which referent topic may be any of
several actual referents [usually intentional puns or attempts to
mislead at the speaker's end or unintentional context failures at the
listener's end]. I suppose this is type (b) ambiguity, since all
implementation-defined things are of this kind.
From: Sam Steingold
Subject: Re: Known inconsistencies or bugs in CLHS?
Date:
Message-ID: <m3elhj5x64.fsf@gnu.org>
> * In message <···············@shell01.TheWorld.com>
> * On the subject of "Re: Known inconsistencies or bugs in CLHS?"
> * Sent on Fri, 12 Apr 2002 18:16:20 GMT
> * Honorable Kent M Pitman <······@world.std.com> writes:
>
> Sam Steingold <···@gnu.org> writes:
>
> > pathnames are required to be printed as #P"" when *PRINT-READABLY* is
> > non-NIL even though when *PRINT-READABLY* is non-NIL objects must be
> > printed so that reading them back results the a similar object.
> >
> > #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")
>
> or #S(PATHNAME :NAME ".A" :TYPE "B")
> or #S(PATHNAME :NAME ".A.B" :TYPE NIL)
> or #S(PATHNAME :NAME NIL :TYPE "A.B")
> or #S(PATHNAME :NAME ".A.B" :type :UNSPECIFIC).
>
> or #S(PATHNAME :NAME ".a.b" :type :UNSPECIFIC).
>
> The first four depending on how the lisp chooses to model internal case.
>
> As has been noted, this is all just in the realm of
> implementation-defined. Once defined, it is not ambiguous at all.
As I tried to explain in my reply to Erik (which he misunderstood,
alas), ambiguity is _not_ what I am unhappy about.
Let me try to clarify:
The fact that the readable representation of a pathname is,
essentially, its namestring means that of the many pathnames with
identical namestrings only _one_ can be printed readably.
I think that this drastic limitation of the number of pathnames that
can be printed readably is not a good idea.
The original poster asked for "bugs" in the standard.
I think that this amounts to a bug (or, at least, a buglet :-)
Another thing is that this lack of #S(PATHNAME) notation _sometimes_
makes it harder to pass pathnames from one implementation to another.
(Yes, I know that pathnames are very dependent on implementations and
the underlying OS and namestrings are the things that should be relied
upon for interchange &c &c &c _Sometimes_ it's nice though to be able
to pass the exact pathnames around.)
--
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
<http://www.palestine-central.com/> <http://www.mideasttruth.com/>
To a Lisp hacker, XML is S-expressions with extra cruft.
Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
> Recently, I've run into the special problem that
> compiler-macro-function returning NIL does not work in CMUCL (in
> contrast to what is written in the CLHS glossary on
> compiler-macro-function). I then found out that this topic was
> discussed in c.l.l. already, and KMP's opinion in
>
> http://groups.google.com/groups?hl=en&selm=sfwso497n0f.fsf%40world.std.com
>
> is that both returning the original form and the symbol NIL should
> work. Now, neither CMUCL nor ACL understand returning NIL, and after
> asking on the CMUCL mailing list about this, I am left with the
> impression that this is an inconsistency within the Hyperspec (when
> reading it first, it seemed unnatural to me as well).
>
> To prevent meeting such a CLHS (or ANSI standard) problem again: what
> further inconsistencies or bugs are known?
It would be technically (X3)J13's job to maintain any official list of
problems with J13, but of course any agency could maintain such a "believed"
list, and it's on my list to do so.
Problems that are properly described as "problems in the HyperSpec" are
only those that are defects in the rendering of the official TeX sources
into HTML, which was done by a custom program that I (as an employee of
Harlequin) wrote. The known problems in rendering are quite small and
barely worth mentioning; they include a place or two where a point size
measurement eeked through or where a couple of sections got numbered funny.
The HyperSpec itself is generated from the identical sources as the ANSI
CL standard, and most problems you see which are "wording problems" (unless
I _really_ goofed) are in the original ANSI CL text.
It's on my list to make a public list of the known problems with both
HyperSpec per se and "believed" problems with ANSI CL. It's just not
quite bubbled to the top of the list yet.