Re: [Pika-dev] fixnum != fixnum [was ping numbers.pika.hackerlab]

[Tom Lord]

    > The latest patch in my tree "basic fixnum support" is bad and evil -
    > don't merge it yet... 

Ok.

    > here's why:

    > Tom Lord <address@hidden> writes:

    > >     --------------------------------
    > >     |                              |
    > >     |  scm/libscm-numbers-reps     |      scm_reps_add normally adds two
    > >     |                              |      numbers but can also instead 
    > >     | implements math routines     |      return 
scm_err_numeric_raise_needed
    > >     | and conversion <-> C types   |
    > >     |                              |      in that case, scm_add converts
    > >     | can add new numeric reps     |      the arguments to the same 
    > >     | using the vtable facility    |      representation and retries
    > >     |                              |      the add
    > >     --------------------------------
    > >     |                              |
    > >     |  scm/reps                    |
    > >     |                              |      fixnum and double 
representations
    > >     |  provides optimized          |      are coded here so that they
    > >     |  representations for         |      can be heavily optimized
    > >     |  fixnums and doubles         |
    > >     |                              |      other new number types just
    > >     |  (also provides GC,          |      use the `vtable' facility
    > >     |   vtable objects, etc.)      |
    > >     --------------------------------

    > Something that eluded me until just now is that earlier when we
    > discussed numbers implementations on IRC, we referred to small
    > integers embedded in t_scm_words as fixnums and integers that needed
    > to be heap allocated as bignums - I must have missed the phase when we
    > started referring to both as fixnums.

You didn't miss it -- it didn't happen.

Fixnums are just what you think they are: small integers (that, along
with tag bits, fit in a single word;  that are immediate values).

Bignum representation stuff belongs in scm/libscm-numbers-reps and
should use a vtable object as their basis of representation.

You could think of it this way:  you could replaces `reps' with a new
implementation, and libscm-numbers-reps shouldn't have to change.
The replacement of `reps' only needs to provide representations (not
even math operators) for fixnums and doubles.


    > So, just to clarify things, the libscm-numbers-reps fixnum code is
    > responsible for dispatch to reps fixnum when it can fit the result
    > into a t_scm_word, but otherwise must create the bignum data.

That sounds about right.

Basically, the math operators and predicates are (to be) implemented
in libscm-numbers-reps.   The low-level details of representations of
number types _other_than_ fixnums (small integers) and boxed doubles
are also to be implemented in libscm-numbers-reps.

The binary math operators and predicates in libscm-numbers-reps _must_
handle all calls in which both arguments have the same representation.
They _may_ handle (optimize) certain cases of the two arguments having
different representations.

If there are any cases where a binary operator or predicate in
libscm-numbers-reps can not handle a pair of differing-representation
arguments, then the operator or predicate should return
scm_err_numeric_raise_needed and the corresponding raise function
(also in libscm-numbers-reps) must be able to convert those two
arguments to two arguments of the same (or otherwise "handled")
representation types.


A call might go:

        scm_add passed a fixnum and a double
          it verifies that both arguments are numbers
          and calls:

        scm_reps_add passed a fixnum and a double
          perhaps it handles this case specially and
          just produces a result, or perhaps it 
          returns scm_err_numeric_raise_needed

        back in scm_add
          call scm_raise_for_binop with the two arguments

        scm_raise_for_binop
          presumably convert the fixnum to a double
          and return

        back in scm_add
          retry the call to scm_reps_add

        scm_reps_add passed a double and a double
          it must produce a result for these 
          same-representation arguments


(Sometime in the future, of course, all of that will be (optionally)
 inlined into scm_add.   The purpose of of this split between 
 scm_add and scm_reps_add is just to abstract out that common 
 pattern of type-checking and representation-raising-as-fallback.)

-t