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 <[email protected]> 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 _______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
