On Tue, 2006-01-31 at 17:17 -0500, Andrew Koenig wrote:
Apart from making 0640 a syntax error (which I think is wrong too), could this be solved by *requiring* the argument to be a string? (Or some other data type, but that's probably overkill.)
That solves the problem only in that particular context.
I would think that if it is deemed undesirable for a leading 0 to imply octal, then it would be best to decide on a different syntax for octal literals and use that syntax consistently everywhere.
+1, and then issue a warning every time the parser sees leading 0 octal constant instead of the new syntax, although the old syntax would continue to work for compatibility reasons.
I am personally partial to allowing an optional radix (in decimal) followed by the letter r at the beginning of a literal, so 19, 8r23, and 16r13 would all represent the same value.
For me, adding the radix to the right instead of left looks nicer: 23r8, 13r16, etc., since a radix is almost like a unit, and units are always to the right. Plus, we already use suffix characters to the right, like 10L. And I seem to recall an old assembler (a z80 assembler, IIRC :P) that used a syntax like 10h and 11b for hex an bin radix.
Hmm.. I'm beginning to think 13r16 or 16r13 look too cryptic to the casual observer; perhaps a suffix letter is more readable, since we don't need arbitrary radix support anyway.
/me thinks of some examples:
644o # I _think_ the small 'o' cannot be easily confused with 0 or O, but.. 10h # hex.. hm.. but we already have 0x10 101b # binary
Another possility is to extend the 0x syntax to non-hex,
0xff # hex 0o644 # octal 0b1101 # binary
I'm unsure which one I like better.