Re: integer overflow handling for most-negative-fixnum

[Stefan Monnier]

>> ELISP> most-negative-fixnum
>> -2305843009213693952 (#o200000000000000000000, #x2000000000000000)
>> ELISP> #x2000000000000000
>> *** Read error ***  Arithmetic overflow error: "2000000000000000 (base 16)
>> is out of fixnum range; maybe set ‘read-integer-overflow-as-float’?"
>> ELISP> #x-2000000000000000
>> -2305843009213693952 (#o200000000000000000000, #x2000000000000000)
>> 
>> If the reader will not accept #x2000000000000000 as input then the value
>> of most-negative-fixnum as a non base10 number octal should have
>> negative sign to ensure consistent handling.

I don't see what this has to do with the reader's behavior on
#x2000000000000000.  The only problem I see above is how to *print*
a value like #x-2000000000000000, which is currently done incorrectly.

> Please don't forget the important use case of showing the hex
> representation of a negative number.  There are situations where I'd
> like to have "M-: -10 RET" display #x3ffffffffffffff6 rather than
> #x-0a.

IIRC this was discussed recently in the context of the introduction of
bignums.  I didn't follow the thread in its entirety, but to me both
behaviors are valid and desirable, so we need some way for the
programmer to choose which one to use when (i.e. print the negative
number as ... well ... a negative number even when printed in a non-10
base, or print it as a "bitfield" where the leading ones of the two's
complement representation are just more bits rather than a negative
sign)

> So I'd prefer we fixed the reader, if that's possible without breaking
> something important.

Not sure what "fix the reader" would do here.  Do you mean read
#x2000000000000000 as a negative number?  When/why/where would that be
a good idea?


        Stefan