[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Parsing numbers

Received: from GEORG.LAAC-AI.Dialnet.Symbolics.COM by ALAN.LAAC-AI.Dialnet.Symbolics.COM via CHAOS with CHAOS-MAIL id 41510; Fri 29-Sep-89 09:56:12 PDT
Date: Fri, 29 Sep 89 09:56 PDT
From: Montgomery Kosma <kosma@ALAN.LAAC-AI.Dialnet.Symbolics.COM>
Subject: Parsing numbers 
To: slug@ALAN.LAAC-AI.Dialnet.Symbolics.COM
In-Reply-To: Your message of 29 Sep 89 09:38 PDT
Message-ID: <19890929165603.3.KOSMA@GEORG.LAAC-AI.Dialnet.Symbolics.COM>
Character-Type-Mappings: (1 0 (NIL 0) (SAGE:SANS-SERIF-BODY :BOLD :NORMAL) "HL12B")
                         (2 0 (NIL 0) (SAGE:SANS-SERIF-BODY :ROMAN :NORMAL) "HL12")
                         (3 0 (NIL 0) (:DEVICE-FONT FONTS:HL12 :NORMAL) "HL12")
                         (4 0 (NIL 0) (SAGE:SANS-SERIF-BODY SAGE::LISP :NORMAL) "HL12B")
                         (5 0 (NIL 0) (SAGE:SANS-SERIF-BODY SAGE::TYPEWRITER :NORMAL) "CPTFONT")
                         (6 0 (NIL 0) (SAGE:SANS-SERIF-BODY :ITALIC :NORMAL) "HL12I")
Fonts: CPTFONT, HL12B, HL12, HL12, HL12B, CPTFONT, HL12I

    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 ,)

[.......]

    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

Well, would it be "wrong" if you had a variable named 1A3 that for some
perverse reason :-) the reader thought was a hexadecimal digit?  It
seems like somebody just had to make a decision about which is higher
priority, interpreting as a symbol or a hex number.  Anyway,  
here's what the manual has to say about it:

       1Reading Integers in Bases Greater Than 10

0       2The reader uses letters to represent digits greater than 10.3 2Thus,
0       2when3 4*read-base*2 is greater than 10, some tokens could be read as
0       2either3 2integers, floating-point numbers, or symbols.3 2The reader's ac-
0       2tion on3 2such ambiguous tokens is determined by the value of
0       4si:*read-extended-ibase-unsigned-number*2 and
0       4si:*read-extended-ibase-signed-number*2.3 2Setting these vari-
0       2ables to 4t3 2causes the tokens to be always interpreted as numbers.3 2A
0       4nil2 setting causes the tokens to be interpreted as symbols or
0       2floating-point numbers.3 2The above variables can have two other, in-
0       2termediate3 2settings, as explained in the Dictionary entry.

0       2Examples:

0            5(setq *read-base* 16) => 16
0            5(+ 10 5) => 210                  5;this works as expected 
0            5(+ c 2) => signals an error because c is an unbound symbol
0            5(setq si:*read-extended-ibase-signed-number* t) => T
0            5(+ c 2) => 14   0                5;now c is read as a number
0            5(+ #xc 2) => 140                 5;always safe 
0       1Compatibility Note2:3 2The fact that the reader depends on the value
0       2of3 2these variables to tell it how to interpret tokens when the value of
0       4*read-base*2 is greater than ten, rather than just automatically3 2inter-
0       2preting them as numbers, is an incompatible difference from the3 2lan-
0       2guage specification in 6Common Lisp, The Language2.

0Good luck!

monty 
kosma@alan.kahuna.decnet.lockheed.com