I haven't thought about this myself very deeply but I assume JP Massar is right, so I submit this little thread from c.l.l as a bug report to the list (SBCL 0.7.10 behaves identically, SCL 1.1.1 doesn't). The full thread is archived at <http://groups.google.com/groups?threadm=3e0775ee.49512429%40netnews.attbi.com>.
On 23 Dec 2002 23:25:47 +0100, Edi Weitz <[EMAIL PROTECTED]> wrote: >[EMAIL PROTECTED] (JP Massar) writes: > >> I believe the Hyperspec says that >> >> (let ((*read-suppress* t)) (read-from-string "#\GARBAGE")) >> >> should return NIL. >> > >edi@bird:/tmp > cmucl >; Loading #p"/home/edi/.cmucl-init". >CMU Common Lisp 18e-pre, built 2002-12-19 on melbourne, running on bird.agharta.de >Send questions to [EMAIL PROTECTED] and bug reports to [EMAIL PROTECTED] >Loaded subsystems: > Python 1.0, target Intel x86 > CLOS based on PCL version: September 16 92 PCL (f) >* (let ((*read-suppress* t)) (read-from-string "#\GARBAGE")) > >NIL >8 > Well, it turns out that the Hyperspec example is just plain WRONG. The Hyperspec example has "#\Garbage" when presumably the intention was to have "#\\Garbage", showing that some unidentified character name is okay when *read-suppress* is T. Using "#\Garbage" should generate an error because there is no dispatch macro for the character 'G'. I don't know why CMUCL does not generate an error.
