--- Numeric Literals ---

decimal notation:
123 # int 123
0123 # int 123
123.0 # num 123.0
-123 # int -123

0_1.2_3 # ok
_01.23 # wrong
01.23_ # wrong
01_._23 # wrong
1__2 # wrong

exponential notation:
-1.23e4 # num
-1.23E4 # num (identical)
1.23_e_4 # wrong

bin/oct/hex notation:

0b0110 # bin
0c0123 # oct
0x00ff # hex
0x00fF # hex, == 0x00ff
0x00FF # hex, == 0x00ff

-0xff # ok
-0x00ff # ok

0xf_f # ok
0x_ff # ok

explicit radix:

(radix 2-32)

20:1gj # base 20
20:1GJ # base 20 (identical)
20:1.G.J # base 20 (identical)
20:1_G_J # base 20 (identical)
20:1.16.19 # base 20 (identical)
20:1_16_19 # NOT identical; == 20:11619
20:1.1_6.19 # WRONG: dotted form may not have underlines

-20:1GJ # base 20 (negative)
-20:1.16.19 # base 20 (negative)

62:zZ # base 62 (?)
62:z.Z # base 62 (identical?)
62:z_Z # base 62 (identical?)
62:Zz # base 62 (not identical?)

(radix 33-RADIX_MAX)

256:0.253.254.255 # base 256
256:0_253_254_255 # base 256


Other issues w/ literals:

- radix <= 32, alpha digits may be upper or lowercase
- underlines may appear ONLY between digits
- dotted form may therefore not have underlines
- radix < 2 throws error
- negative sign goes before radix, e.g. -20:1GJ, in
order to match usage in cases like -0x00ff.
- need to specify RADIX_MAX

- can't have runtime radix, e.g. 2**8:10, because : binds
tighter. can't say (2**8):10, because not a literal
anymore, and ':' is used for adverbial in many locations
(ambiguous).

- need to verify that 0b1, 0c1, 0x1 are still allowed in addition to explicit radix (but seems appropriate to leave them in, given their frequency.)

MikeL

Reply via email to