Re: [Chicken-hackers] [PATCH][5] types.db entries for the overflow-aware ops

[lemonboy]

Hi Peter,
I expect the `fxX?` procedures as 1:1 replacements of the standard
`fxN` ones with the
only exception being the way the overflow is handled.
The point where the two diverge is the handling of the input
parameters: while the latter
follow the garbage-in garbage-out philosophy the former takes a
"stricter" approach and
rejects the non-fixnum arguments by returning `#f`.
I think that's the by-product of a lax check on the input parameters
rather than a design
decision and even though this check works just fine in practice there
are some drawbacks:
- We can't give to their arguments the type `(or fixnum false)`, this
means we can't possibly
 warn the user if they pass the wrong argument (the standard
procedures allow this);
- There's no way to distinguish the result of `(fx+? 'foo 3)` from the
result of an
 overflowing calculation, couple it with the lack of any warning and
you're in for a nice bug
 hunt.

Cheers,
Lemonboy

On 19 May 2017 at 22:54, Peter Bex <address@hidden> wrote:
> On Fri, May 19, 2017 at 10:48:38PM +0200, lemonboy wrote:
>> Hello hackers,
>> there's not much more to say.
>
> I'm wondering, is it defined only for fixnums and false, or is it
> part of the API that it allows any non-fixnum object?
>
> (fx+? 'hi 'there) => #f
>
> In that case, the type shouldn't be
> (fx+? (or fixnum false) (or fixnum false)) => (or fixnum false)
> but
> (fx+? * *) => (or fixnum false)
>
> Cheers,
> Peter