Re: Making 'eq' == 'eql' in bignum branch

[Andy Moreton]

On Mon 20 Aug 2018, Paul Eggert wrote:

> Andy Moreton wrote:
>
>> There will always be a performance diffrence between fixnum and bignum
>> values, and it may be useful for performance tuning to have a simple way
>> to discover where that boundary lies.
>
> Performance nerds can use 'most-positive-fixnum' and 'most-negative-fixnum'
> for that sort of thing. These constants have been there for some time and are
> not going away. My objection is to 'bignump' and 'fixnump', which are no more
> necessary as primitives than 'negativep' would be.

Pip Cet was advocating removal of most-positive-fixnum, and that is what
I was objecting to as being too severe. We do not need negativep as we
already have other prmitives for testing that property.

>> These are used in the tests to ensure that implementation is correct,
>> and that values in fixnum range are always represented as fixnums, not
>> bignums. How do you propose to test that without these predicates ?
>
> Tests can use 'most-positive-fixnum' and 'most-negative-fixnum', constants
> that tests need to use anyway in order to generate values like (1+
> most-positive-fixnum). So they can survive quite well without 'bignump' and
> 'fixnump' as primitives.

You have avoided the question.

The current codebase assumes that lisp bignum objects only exist for
values outside fixnum range. Without fixnump how can tests check that
values within fixnum range actually have a fixnum representation ? How
can test check that no bignum object is created for a fixnum value ?

    AndyM