At 02:37 PM 12/4/98 , Bill Frantz wrote:
>Should E have hex input support. Output support in "any" radix (up to 36)
>is available via toString(radix). For example:
> ? 22 toString(16)
> # value 16
It definitely needs to be about as easy for a C-tradition programmer to type hex and octal numbers as in C, and it definitely needs to be easy for a C-tradition programmer to figure out how to do so without reading the manual. The path of least resistance would be to adopt C's leading "0x" and "0" conventions.
However, it bugs me to do these rather than provide a way to enter in a number with an arbitrary in-range radix. Smalltalk uses the format <radix>r<digits>
with <radix> itself, of course, expressed in base 10. For example, as I just tried in Squeak,
2r1010101 evaluates to 85, while 3r1010101 evaluates to 820.
I think I'd really like to adopt this convention *instead* of C's hex and octal convention, especially since (as with "="), the error message when they use the C convention can explain how to use the new convention instead. Hypothetically:
? seconds := 0x7fffffff/1000 # problem: Use 16r<digits> for hex rather than 0x<digits> ? seconds := 017777777777/1000 # problem: Use 8r<digits> for octal rather than 0<digits>
Would this change of convention increase the perceived cost of learning E? On the one hand, I don't care about this issue enough to risk reducing E's audience. OTOH, the only ones that would notice are those that play with bits -- can they stand a bit of novelty? Feedback solicited. How does Python or Perl deal with numeric bases?
On a related note: Chip or Bill, what's our encoding scheme for turning
large numbers into parts of a "cap:" URL?
Assuming it's in base 64 and involves no syntactically problematic
characters, does it make sense to extend numeric input and output so that
it accepts radixes 2 through 36 and 64?
Assuming it's in base 64 and involves no syntactically problematic characters, does it make sense to extend numeric input and output so that it accepts radixes 2 through 36 and 64?
36rMARKM == 37453846 --I am not a number. PGP Fingerprint = 0EE0 1510 0700 E51B 1CCF 7C4B 8CE1 4E7F C9EB 83B1 --Well, maybe I am.