net@tub.UUCP (Oliver Laumann) (03/22/90)
In article <2063@laura.UUCP> muenx@heike.informatik.uni-dortmund.de (Holger Muenx) writes: > I think I found a small bug in MIT-Scheme V7.0. Look at the following > transcript: > > 1 ]=> (eq? (string->symbol "loadConst") 'loadConst) > > ;Value: () It ain't no bug. The standard says (in the section explaining symbol->string): "If the symbol was part of an object returned as the value of a literal expression [..] then the string returned will contain characters in the implementations preferred standard case [..]. If the symbol was returned by string->symbol, the case of the characters in the string returned will be the same as the case in the string that was passed to string->symbol." Thus, since 'loadConst is a literal, the characters are transformed into the "preferred case" by the reader, which I think is upcase in C-Scheme, i.e. the name of the symbol actually is LOADCONST. On the other hand, the case of the characters in the name of the symbol created by the above call to string->symbol is preserved, which is the reason why eq? returns () (well, I wish it would return #f, but that's another story...). Now let me turn your attention to a real bug in C-Scheme: The C-Scheme reader refuses to parse numeric constants like #o-10 (i.e. a radix followed by a sign followed by digits). On the other hand, it happily accepts something like -#o10. This must be a bug, since the standard clearly says that the radix, like the exactness specification, is a prefix (see page 37 of the P1178/D3 or page 32 of the R^3.99RS), so #o-10 is the correct form, while -#o10 should be parsed into two objects, the symbol "-" followed by #o10. Regards, -- Oliver Laumann, Technical University of Berlin, Germany. pyramid!tub!net net@TUB.BITNET net@tub.cs.tu-berlin.de