Chip Morningstar chip@communities.com
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
>	<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?  

[-] Low-level lexical conventions are the things that the experienced
C/C+++/Java programmer's eye will be most sensitive to.

>Feedback solicited.

[-] 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: '='.