Sat, 5 Dec 1998 11:41:45 -0800 (PST)
>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.
[+] I was *astonished* to learn that E didn't already support these
conventions. To me these are a default part of the C-style lexical rules and
their lack simply means that the E lexer is broken.
>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
>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
> ? 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?
[-] Low-level lexical conventions are the things that the experienced
C/C+++/Java programmer's eye will be most sensitive to.
[-] Please don't do this. The whole support-any-radix-you-want thing is cute
but actually not terribly useful. As I understand it, one of the design
heuristics for E is, "when faced with a choice between elegant-and-more-ideal-
but-a-little-alien on the one hand and imperfect-but-workable-and-very-familiar
on the other hand, pick the latter". Use this heuristic here.
>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?
[-] The base 64 encoding uses at least one character that *would* be
syntactically problematic: '='.