[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Parsing numbers
Date: Fri, 29 Sep 89 09:13:53 pdt
From: hall@CTC.FMC.COM (David Hall)
I was trying to read some numbers on a MacIvory (Genera 7.4) and
noticed some peculiar behavior. I got the same results on a 3640
running 7.2. (In the following examples the LET form was evaled,
the number after ON was entered and the thing after the -> was
returned. (TYPE-OF *) yielded the thing after the ,)
1read0 is not particularly careful in what is valid as a number. You
should not really be using 1read0 as a tool to construct a user-interface.
Use 1accept0 instead, e.g., (accept '((integer) :base 2))
First a binary example. This is what one would expect:
(let ((*read-base* 2)) (read)) on 1111 -> 15 , FIXNUM
I guess this next example is OK in a perverse way, i.e. it would be
correct if 9 were a binary digit with value 8 greater than 1.
(let ((*read-base* 2)) (read)) on 1191 -> 31 , FIXNUM
Now a hexadecimal example. Again, this is the expected result:
(let ((*read-base* 16)) (read)) on 123 -> 291 , FIXNUM
But this next one is wrong. "A" is a perfectly good hexadecimal digit
and should not be interpreted as an alphabetic.
(let ((*read-base* 16)) (read)) on 1A3 -> 1A3 , SYMBOL
CLtL does not specify what 1type-of0 should return. In fact, it is
permissible for it to always return 1t0. (ANSI CL will specify this
better). The Symbolics implementation of 1type-of0 does somewhat better
than that, but does not look at the dynamic environment to figure out
what to return. You should really never depend on the value returned by
1type-of0 for anything "important".
I expected the second example to result in a symbol named |1191| and
the fourth to result in a number with decimal value 419. Any relevant
advice on how number parsing does or should work?
Thanks,
--David Hall.
Hall@ctc.fmc.com
FMC Corporation
1205 Coleman Avenue
Santa Clara, CA 95052