On Thu, 2 Mar 2000, Dwight Hughes wrote:

> Bert Freudenberg wrote:
> > 
> > On Wed, 1 Mar 2000, Dan Ingalls wrote:
> > >
> > > 1.  I much prefer 2r1e31 to 2r10000000000000000000000000000000 for the
> > > sign bit and 16rFe8 for the high nibble of a 32-bit integer and 10e6
> > > for a million.  Come on.
> > 
> > We do agree here, except for the hex case. I find 16rF0000000 more
> > readable (and, btw, more correct - which prooves my point) to refer to the
> > hi nibble than the exponent notation. 
> 
> Dan obviously meant 16rFe7 -- that's an F followed by seven zeroes - how
> difficult is that to understand?

Maybe I'm more "visual". I immediately "see" a bit pattern in
16rF0000000, but not in 16rFe7. I know there must be 8 hex digits in a 32
bit number. It's easier to get wrong with the exponent notation, as Dan's
(freudian?) slips demonstrated (a million is 1e6). For example, to get the
next to highest nibble I'd rather write 16r0F000000 than 16rFe6.

> I don't even have to count the zeroes to make sure I put in the
> correct number of them. It means the exact same as 16rF * (16
> raisedTo: 7) -- precisely as one would logically expect.

Sure I know it means the same. I personally think it's harder to read
_for hex numbers_ because 'e' is a valid hex digit everywhere else.

> Well, you're increasing the amount of syntax and arbitrary detail and
> exceptions to remember - so I guess that can be considered "widening"
> the syntax. I don't think that is a direction I would want to go in
> though. 

I don't add a bit to the syntax. It might be a rule more to the compiler,
but it's one less for me to remember.

> > Here's a short form of what my proposal was: Within the current number
> > syntax, allow case insensitive letters, but only allow exponent notation
> > with $e for bases <= 10.
> 
> Repeat after me, "creating arbitrary gratuitous limitations is a Bad
> Idea".

It's not arbitrary, but it's exactly the limit up to which you can express
a number with numeric digits. It's the logical consequence if arbitrary
letter digits are allowed. This definition still is much wider than ANSI
which only allows exp notation for base 10 floats.

> This sort of thing reminds me of chocolate-covered manhole covers, but
> if you _must_ have lowercase digits, then define "R" with "E" for
> lowercase digits and the current "r" with "e" for uppercase digits -- so
> 16rABCDEFe9 = 16RabcdefE9.

That's not what I want - I just don't care about the case. Actually, I
don't even insist on changing the Squeak syntax (although that would come
handy), because when writing code, the compiler immediately reminds me of
the number format. I'd probably stay with uppercase hex digits anyway.  

I just want a case insensitive conversion from hex strings to numbers. It
seemed natural to me to get the problem at it's roots, and it needed only
a minor change to the system. It's just another incarnation of "if you do
it right, you only need to do it once".

  -Bert-