Re: [Chicken-hackers] [PATCH] Re: make check failing

[Felix]

>> 
>> Attached is a patch that corrects the behaviour of
>> C_i_foreign_[unsigned]_integer64_argumentp (there where bugs in both
>> the signed and unsigned variant).
> 
> Thanks!  A question though: Shouldn't C_i_foreign_integer64_argumentp
> also check that the flonum is an integer (ie, there's nothing after the
> decimal point)?

It could. Should it? C just truncates. I dunno.

> I think we should seriously consider supporting bignums in core.  

Argh.

> They won't add much extra overhead in terms of optimizations

I think quite the opposite is the case, but I'm usually wrong with my
performance estimations. The only option is probably to try it out,
which is a lot of hard work.

> ; the scrutinizer
> already needs to consider the possibility that a fixnum overflows into a
> flonum.  Overflowing into a bignum isn't much different.  In fact, it's
> slightly more precise because you know that they're always integral,
> while you lose that information when switching to flonums.  This at least
> allows for some (admittedly trivial) optimizations you don't get when
> using flonums, like knowing that integer? and exact? return true.

I don't think that it adds many optimization options.

> Besides, you won't lose information which helps srfi-4 64 bit types make
> sense, and simplifies the part of the FFI currently under consideration.

That is one case. It also _could_ simplify a lot of FFI code and handling
of word-sized integers in general. 

I get cramps thinking of all the work that would have to go into such
a project.


cheers,
felix