Sat, 5 Dec 1998 02:30:16 -0800 (PST)
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
> 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.