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

*To*: SUSSMAN@G.BBN.COM, gjs@MC.LCS.MIT.EDU, JAR@AI.AI.MIT.EDU*Subject*: Scheme number notation*From*: Mark A. Sheldon <DEATH@XX.LCS.MIT.EDU>*Date*: Mon, 8 Feb 88 17:47 EST*cc*: rrrs-authors@MC.LCS.MIT.EDU*In-Reply-To*: <[G.BBN.COM] 8-Feb-88 09:35:01.SUSSMAN>

R3RS doesn't say what the meaning of E notation (for the exponent) is. In MIT C/Scheme, apparently <stuff>e<exp> means <stuff>*10^<exp> regardless of the base. E.g. #b1e2 is 100 decimal, not 100 binary. You're right that R3RS leaves the notation for exponents underspecified. I discovered this when I used some of the MIT Scheme number-parser code to write my own reader. My reader now uses the radix specified in the prefix (if any) as the radix for reading the exponent. Thus #b1e2 is 100 binary. Worse yet, though the lexical grammar allows E<exp> with any base, it can't work with hex, since E is a hex digit. Hence, #b1E2 = #o1E2 = 1E2 = 100 but #x1E2 = 482 I also ran into the problem with E in hex: without thinking about it, I formulated the test case 1.1E-2 and got reader errors (obviously). Since E notation is really just a hold-over from FORTRAN, why not use ^ instead? It would look nicer and wouldn't conflict with any reasonable radix. Another problem in implementing a reader in Scheme is that R3RS also underspecifies the relationships among the return values of CHAR->INTEGER. There is no guarantee that the numeric characters are together in the character code. My reader (and the MIT Scheme reader) relies on this anyway. -Mark

**Follow-Ups**:**Scheme number notation***From:*Mark A. Sheldon <DEATH@XX.LCS.MIT.EDU>

**References**:**Scheme number notation***From:*SUSSMAN@G.BBN.COM

- Prev by Date:
**Wording to fix for LETREC** - Next by Date:
**A Minimalist Standard** - Prev by thread:
**Scheme number notation** - Next by thread:
**Scheme number notation** - Index(es):