Hex

[Ka-Ping Yee]

On Sat, 5 Dec 1998, Mark S. Miller wrote:
>
> 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.

[+] Agreed.  My immediate reaction to Bill's message was some surprise and
an expectation for the "0" and "0x" conventions in E as soon as possible.

> 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>
[...]
> 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

[-] This is a nice generalization, but probably not worth it.  I have
never come across a desire to enter numbers into programs in any base
other than 10, 16, 2, or 8 (for me octal is extremely rare, and i think
binary would have been a much better choice for some easy syntax).  In
any case, the C convention is fairly universal, and probably should not
be left unavailable.

Providing the Smalltalk arbitrary-radix format as an additional option
would be okay, if you don't mind the extra complexity.  My bet would be
that, if it's provided, it will just get used 99% of the time for binary
numbers and normal vocabulary will just come to include "0x", "0", "2r".
What's your experience with using this feature in Smalltalk?

> 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?

[#] Python, Perl, and Tcl all accept "0x" for hex and "0" for octal.

> 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?

[#] Base 64 is an interesting idea, but i bet base64 would be rarely used
for constants and more often wanted as a conversion function.


!ping