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

[Peter Bex]

On Sun, May 21, 2017 at 05:14:02PM +0200, lemonboy wrote:
> 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);

I don't really care that much about this, so unless others have similar
concerns I think we can apply this change.

However, they shouldn't be #:enforce; they don't raise an error when
their types are fixnum or false, which is what enforce means: if the
code goes beyond this expression, you may assume the input types are
correct.

I believe these procedures can be marked #:pure, though, since they
don't have *any* side effects (except for fx/?, since it will raise an
exception when dividing by zero).

Speaking of which: can't all the other fixnum-specific procedures be
pure as well?  Except for fx/, of course.

> - 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.

Speaking of strange bugs, I'm wondering whether these fixnum procedures
should be foldable at all (that also goes for the procedures that are
already in types.db).  Consider the case where you're compiling on a
64-bit machine.  The compiler folds the fixnum operations at
compile-time, resulting in a fixnum.  However, if the fixnum is not
representable as a fixnum on the target computer, it will be represented
as a bignum (or on CHICKEN 4, as a flonum).

This not only produces a different answer than when the same code would
be compiled on the 32-bit machine and in the interpreter, but it also
may trigger other unexpected behaviour resulting from a mismatch of the
expectation that you're dealing with fixnums only.  For example, a
specialised unsafe version of a generic procedure might end up being
specialised for fixnums, but on a 32-bit platform it might still receive
a bignum (or a flonum on master).

Hm, I wonder if this stuff causes other problems as well...

Anyway, attached is a signed-off version of your patch without
the #:enforce and with the #:pure annotations, and a second patch
which removes #:foldable from the other fixnum operations too.

Cheers,
Peter

0001-Add-entries-in-the-types.db-for-the-fxX-ops.patch
Description: Text Data

0002-Remove-foldable-for-fixnum-specific-ops.patch
Description: Text Data

signature.asc
Description: Digital signature