[racket] Parsing Numbers

[Ewan Higgs]

Hi all,
I've been playing with the number tower in Racket and I noticed it appears to
drift from the R5RS and R6RS standard. Now, I know the Racket rebrand grants PLT

Scheme to now drift from the standard, but I think this may actually be
unintentional. So let me know if I've misunderstood this.

Section 7.1.1 or R5RS [1] states:

"""
<number> -> <num2> | <num8> | <num10> | <num16>

The following rules for <num R>, <complex R>, <real R>, <ureal R>, <uinteger R>,

and <prefix R> should be replicated for R = 2, 8, 10, and 16. There are no
rules for <decimal 2>, <decimal 8>, and <decimal 16>, which means that numbers
containing decimal points or exponents must be in decimal radix.
"""

Section 4.2 of R6RS [2] states:
"""
The rules for <num R>, <complex R>, <real R>, <ureal R>, <uinteger R>, and
<prefix R> below should be replicated for R = 2, 8, 10, and 16. There are no
rules for <decimal 2>, <decimal 8>, and <decimal 16>, which means that number
representations containing decimal points or exponents must be in decimal radix.
"""

However, Racket accepts number representations with decimals or exponents [3].
Trying this out on other implementations of varying conformance, I see that SISC

[4], Bigloo [5] and Guile [6] don't allow this. Am I misunderstanding the
specification here or is this a bug or is Racket intentionally doing something
outside the standard?

Thanks for the help!
Ewan

[1]
http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-10.html#%_sec_7.1.1

[2] http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-7.html#node_sec_4.2
[3] Here's what I put into Racket:
Welcome to Racket v5.0.
> 1.0
1.0
> 1e10
10000000000.0
> #o6
6
> #o60
48
> #o60.3 ;<===
48.375
> #b10
2
> #b10.10 ;<===
2.5
> #b10e10 ;<===
8.0
This doesn't seem correct. #o and #b shouldn't accept decimals or exponents. It
should either return two values as entering "> 1 1" would or it should yield an
error.

[4] Here's what I put into SISC 1.16.6:
#;> 1
1
#;> 1e10
1.0e10
#;> #o6
6
#;> #o60
48
#;> #o60.3
Error in read-code: error reading from port '#<character-input-port>':
unexpected token where number was mandatory.

---------------------------
To enable more detailed stack tracing, set the dynamic parameter
max-stack-trace-depth to a non-zero value, e.g. 16.
---------------------------
Some stack trace entries may have been suppressed. To see all entries set the
dynamic parameter suppressed-stack-trace-source-kinds to '().
#;> #b10
2
#;> #b10.10
Error in read-code: error reading from port '#<character-input-port>':
unexpected token where number was mandatory.

#;> #b10e10
Error in read-code: error reading from port '#<character-input-port>':
unexpected token where number was mandatory.

[5] Here's what I put into Bigloo (3.4a)
1:=> 1
1
1:=> 1e10
1.0e10
1:=> #o6
6
1:=> #o60
48
1:=> #o60.3
48
1:=> 0.3
1:=> #b10
2
1:=> #b10.10
2
1:=> 0.1
1:=> #b10e10
2
1:=> *** ERROR:eval:
Unbound variable (from top-level) -- e10

What bigloo does is more surprising at first since it's parsing the octal
#o60.3 as two numbers, #o60 and 0.3. And it's correct to yield an error with
#b10e10. But I think this is inline with the standard.

[6] Here's what Guile 1.8.7 says:
guile> 1
1
guile> 1e10
1.0e10
guile> #o6
6
guile> #o60
48
guile> #o60.3
ERROR: In procedure scm_lreadr:
ERROR: #<unknown port>:5:1: unknown # object
ABORT: (read-error)
guile> #b10
2
guile> #b10.10
ERROR: In procedure scm_lreadr:
ERROR: #<unknown port>:7:1: unknown # object
ABORT: (read-error)
guile> #b10e10
ERROR: In procedure scm_lreadr:
ERROR: #<unknown port>:8:1: unknown # object
ABORT: (read-error)

_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users

[The Configurator]

On Wed, Aug 4, 2010 at 23:04, Ewan Higgs <ewan_...@yahoo.co.uk> wrote:

<snip> 

It should either return two values as entering "> 1 1" would or it should yield an
error.

It should definitely not return two values. That would make no sense at all since there's no separating character. According to the spec it's an invalid value, i.e. a reader error.

But why not expand on the standard? I don't see anything wrong with adding features and extra functionality - as long as strict standard-complying code will run the same way.

[Matthew Flatt]

At Wed, 4 Aug 2010 22:04:11 +0000 (GMT), Ewan Higgs wrote:
> Hi all,
> I've been playing with the number tower in Racket and I noticed it appears to
> drift from the R5RS and R6RS standard. Now, I know the Racket rebrand grants
> PLT
>
> Scheme to now drift from the standard, but I think this may actually be
> unintentional. So let me know if I've misunderstood this.

Racket intentionally extends the syntax of numbers.

The Racket specification is here:

http://docs.racket-lang.org/reference/index.html

and the syntax of numbers is specifically here:

http://docs.racket-lang.org/reference/reader.html#%28part._parse-number%29