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

*To*: slug@WARBUCKS.AI.SRI.COM*Subject*: Parsing numbers*From*: "kosma%ALAN.LAAC-AI.Dialnet.Symbolics.COM %ALAN.kahuna.DECNET.LOCKHEED.COM"@WARBUCKS.AI.SRI.COM*Date*: Fri, 29 Sep 89 12:57:02 EDT

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

- Prev by Date:
**Parsing numbers** - Next by Date:
**Parsing numbers** - Previous by thread:
**Parsing numbers** - Next by thread:
**Request for MacIvory Information** - Index(es):