[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?

    --David Hall.
      FMC Corporation
      1205 Coleman Avenue
      Santa Clara, CA 95052